Is Classifying Distributed Systems as CP or AP a False Dichotomy?

Revisiting Consistency

The CAP theorem defines consistency as linearizability, a very strong guarantee that a read sees the most recent write as if there were a single copy of the data. The article illustrates this with Alice and Bob checking the 2014 World Cup final: Alice sees the correct result, Bob, querying a stale replica, sees an outdated result, violating linearizability because Bob cannot know which request was processed first without external communication.

Achieving linearizability requires extensive coordination, often involving memory barriers on modern CPUs, and is expensive because it forces the system to behave as if only one replica exists even when multiple copies are present.

Revisiting Availability

In CAP, availability means every request that reaches a working database node must return a non‑error response. The article points out that many “high‑availability” systems only provide failover or circuit‑breaker behavior, which does not satisfy this strict definition. Moreover, CAP ignores latency, yet real‑world services consider response time critical; a system that takes minutes to respond is not usable despite meeting the formal availability definition.

CP vs AP Trade‑offs

Using a two‑data‑center example, the article shows two choices when a network partition occurs:

Continue allowing writes in both centers, leading to divergent data and a breach of linearizability.

Restrict all reads and writes to a single leader data center, preserving linearizability but violating CAP’s availability because the non‑leader cannot serve requests.

These choices illustrate the proof of the CAP theorem and demonstrate that the decision is often driven by network latency rather than pure partition handling.

The article also notes that most software does not fit neatly into CP or AP categories; forcing such a classification forces redefinition of consistency or availability, rendering the CAP theorem inapplicable.

Conclusion

Because the binary CP/AP split oversimplifies the nuanced trade‑offs of real distributed systems, the author suggests abandoning the interview question “Which frameworks are CP or AP?” and instead focusing on understanding the underlying guarantees, latency constraints, and broader failure scenarios.