True Partitions are rare; For most datacenters, the ingress and egress port (fiber link to the outside world) is the same, and if they have redundancies they have enough and are self-healing enough that it&#x27;s all-or-nothing - Either you&#x27;re down, and can safely consider that node &#x27;lost&#x27;, or you&#x27;re not, and you can communicate with it.<p>Remember that CAP refers to the whole network. When you partition, you can safely ignore a large portion of the network. So long as you have greater than half in a network shard, you can continue serving safely from that section. If you have datacenters A, B, and C, if C drops from the network consistently, you can still serve traffic from A and B while C is down - And your logic should be built to handle this case. AWS and similar frameworks give you all the tools you need to build this. If you&#x27;re multihoming your IP, your backend detects the partition, and stops offering the route. If you&#x27;re using an ELB, you start failing health-checks [1]. Partitions are not rare - Full service partitions, where A, B, and C are in their own shards, are, and you have the tools to deal with it.<p>On the other hand, where the P still matters a lot is in speed. If you need replicas of data in the US, Europe, and Asia, you&#x27;re going to have a bad time - For all three to agree takes &gt;100ms, even in the best case. That is where you start thinking of the tradeoffs - Do you sacrifice unified-worldview for speed? The answer is almost certainly yes - Very few idioms require unified worldview, even banking.<p>[1] <a href="http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;ElasticLoadBalancing&#x2F;latest&#x2F;DeveloperGuide&#x2F;elb-healthchecks.html" rel="nofollow">http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;ElasticLoadBalancing&#x2F;latest&#x2F;Devel...</a>