Let's consign CAP to the cabinet of curiosities
Claims that modern cloud infrastructure makes the CAP theorem irrelevant draw strong pushback from engineers who design and operate distributed systems. Commenters argue that even with load balancers, managed databases, and highly redundant networks, real-world partitions, latency spikes, and subtle failure modes still force hard tradeoffs between consistency and availability, especially across regions and availability zones. Many see CAP (and related models like PACELC and FLP) as a useful way to reason about these tradeoffs and to communicate impossibility results to stakeholders, even if cloud services hide some of the underlying complexity.
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.