I know this is the man who formulated the CAP Theorem to begin with, but I am shocked to hear him say "partitions are rare" without any justification. Could somebody please expound on this, as my bread&butter comes from building distributed databases, and I can assure you I encounter faulty networks all the time. Am I just crazy, or call me maybe?
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's all-or-nothing - Either you're down, and can safely consider that node 'lost', or you're not, and you can communicate with it.
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're multihoming your IP, your backend detects the partition, and stops offering the route. If you'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.
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're going to have a bad time - For all three to agree takes >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.
It's the small blips that cause the most problems, as correctness issues in your C can show up then and they're much more common than full-on partitions.
