The quality of your C code running on a single node is by all accounts really good. But you sometimes speak about distributed systems in a way that is not correct to people who have really spent a lot of time making these things work at scale.<p>I&#x27;ve done distributed systems, and in fact I usually don&#x27;t implement systems that are 100% correct under maximally-adverse conditions, for performance and convenience reasons. But it&#x27;s important to know and acknowledge where and how the system is less than 100% bullet-proof, so that you can understand and recover from failures. When you have 1000 servers, some virtual in the cloud, some in a colocation facility, and maybe 10 or 20 subtle variants in hardware, you will get failures that <i>should not happen</i> but they do. For example, I&#x27;ve had an AWS host where the system time jumped backwards and forwards by 5 minutes every 30 seconds. And I&#x27;ve seen a tcp load-balancer appliance managed by a colo facility do amazingly wrong things.<p>The point is, you need to understand where the consistency scheme in a distributed system is &quot;fudged&quot;, &quot;mostly reliable&quot;, &quot;as long as conditions aren&#x27;t insane&quot;, and where they are really guaranteed (which is almost nowhere). Then you can appropriately arrange for &quot;virtually impossible&quot; errors&#x2F;failures to be detected and contained. This ad-hoc logic you bring to the problem of distributed systems doesn&#x27;t really help.<p>Not to &quot;dogpile&quot;, but elucidate for others who may not know some of the history here: <a href="https:&#x2F;&#x2F;aphyr.com&#x2F;posts&#x2F;287-asynchronous-replication-with-failover" rel="nofollow">https:&#x2F;&#x2F;aphyr.com&#x2F;posts&#x2F;287-asynchronous-replication-with-fa...</a>
and the also interesting reply: <a href="http:&#x2F;&#x2F;antirez.com&#x2F;news&#x2F;56" rel="nofollow">http:&#x2F;&#x2F;antirez.com&#x2F;news&#x2F;56</a>