Given that they consider durable logging to be a key non-functional requirement, I&#x27;m not sure how ditching durability is a win.<p>Single ordered delivery is hard. Really hard. It&#x27;s easier to allow multiple delivery and&#x2F;or unordered delivery -- if your log entries are given various correlating UUIDs and signed, this makes the whole problem about fifty hojillion times easier.<p>Loggregator[1] and Doppler[2] use UUIDs to identify request, app and agent, which makes it easier to allow logs to arrive out of order from multiple sources and then be reassembled.<p>One thing that helps a <i>lot</i> is to separate metrics from logs. Logging frameworks get overloaded into metrics systems. Logs are useful if you are recording essentially unique events (&quot;I started at ...&quot;, &quot;there was a request for &#x2F;foo at...&quot;). They are wasteful of high QOS resources if you&#x27;re looking at <i>statistical</i> data in which <i>fine-grained event identity isn&#x27;t relevant</i> (&quot;57Mb is used by this process&quot;, &quot;this request took 100ms&quot;).<p>For metrics it is better to use lossy sampling and derive a statistical view of goings on, rather than trying to capture every single data point.<p>A log entry should be like a page in your personal diary on your birthday. A metric is a phone survey asking your age. If you don&#x27;t answer the survey, the data is still useful even with standard error.<p>Edit: I forgot my usual disclaimer that I work for Pivotal Labs, a division of Pivotal, which is the leading contributor of engineering effort on Cloud Foundry.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;cloudfoundry&#x2F;loggregator" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cloudfoundry&#x2F;loggregator</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;cloudfoundry&#x2F;loggregator&#x2F;tree&#x2F;develop&#x2F;src&#x2F;doppler" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cloudfoundry&#x2F;loggregator&#x2F;tree&#x2F;develop&#x2F;src...</a>