Let's consign CAP to the cabinet of curiosities

Scope of CAP in Cloud Environments

• Many commenters argue CAP still fundamentally applies, even in cloud setups with sophisticated networking and managed services.
• Some accept that for many typical SaaS workloads, cloud abstractions and consensus-based services make explicit CAP reasoning less frequent in day‑to‑day work.
• Others say the article effectively assumes away partitions (“the cloud is always available”), which they see as unrealistic and circular.

Critiques of the Article’s Argument

• Several point out that routing clients to a “healthy” side via DNS/load balancers does not remove partitions; it just pushes the CAP trade‑off into other components (LBs, consensus services, DNS).
• The depiction of clients never being “stranded” with an unhealthy partition is seen as idealized; real networks have partial, asymmetric failures and multiple simultaneous partitions.
• Some say the piece conflates “rare enough that I accept the risk” with “irrelevant,” and confuse centralized systems with truly distributed ones.

Practical Experiences & Failure Modes

• Multiple anecdotes: flaky cables, overloaded nodes, cloud networking glitches, and Elasticsearch/Postgres cluster issues causing data corruption or nonsensical results.
• People stress that partitions are not only inter‑DC events; they can be intra‑DC, transient latency spikes, or misconfigurations (e.g., firewalls, bad health checks).
• Banks and payment systems are used as examples on both sides: sometimes preferring consistency (“rather be down than wrong”), sometimes preferring availability with reconciliation and legal/financial backstops.

Conceptual Clarifications & Alternatives

• Commenters emphasize that CAP formalizes a fundamental limit, not a design template; whether it’s “important” is workload‑dependent.
• Several note that quorum/consensus (Paxos/Raft, Spanner‑like systems, multi‑AZ quorum DBs) are concrete ways to pick a side of CAP, not ways to “beat” it.
• PACELC and other models (e.g., FLP, latency vs consistency, DDIA’s critique of labeling systems CP/AP) are cited as more nuanced or helpful in modern practice.

Teaching & Design Takeaways

• Some agree CAP is overused as a teaching entry point; others insist it remains essential conceptual groundwork for anyone designing novel distributed systems.
• Overall consensus: you can offload implementation details to cloud providers, but you cannot offload the business-level choice between availability and consistency when partitions (or their practical equivalents) occur.