&gt; I think the point being made here is that &quot;what your application needs&quot; is often something you chose your way into, and can choose your way back out of<p>I think that while this may be true for many requirements, consistency is among the least flexible ones. Besides, losing consistency usually makes your system <i>more</i> complicated, not less. Weak consistency has some real benefits (latency in some cases, tolerance for more failure modes), but simplicity is not usually one of them.<p>&gt; In other words: if you set out to create Bitcoin in 1998, you might end up running into distributed consensus problems that are difficult enough that you decide to &quot;solve an easier problem&quot;—such that you end up creating Paypal instead.<p>I don&#x27;t think that the design problems behind Bitcoin are any easier than distributed consensus, which, BTW, is not necessary for quite a few consistency levels.