#Consistency and the CAP Theorem: A System Design Guide

The CAP theorem is the first concept most interviewers reach for when probing your knowledge of distributed systems. It frames every data store decision you will ever make at scale.

Proposed by Eric Brewer in 2000 and later formalised as a theorem, CAP says a distributed data store can guarantee at most two of three properties: Consistency, Availability, and Partition tolerance. You cannot have all three.

This guide explains what each property actually means, what the real tradeoff looks like in practice, and how to talk about it confidently when an interviewer asks.

##The Core Concept

Consistency (C) means every read receives the most recent write or an error. All nodes in the cluster agree on the same value at the same time.

Availability (A) means every request receives a response (not necessarily the most recent data). The system stays operational and does not return errors.

Partition Tolerance (P) means the system continues to operate even when network messages between nodes are lost or delayed.

Here is the key insight: network partitions happen in any real distributed system. Packet loss, delayed connections, and split networks are a fact of life. This means P is not optional.

Because you must tolerate partitions, the real choice is: during a partition, do you stay consistent or stay available?

A CP system sacrifices availability to preserve correctness. An AP system sacrifices correctness to stay available. Neither choice is universally better. It depends on what your system needs.

##Consistency Models

Not all consistency is the same. There is a spectrum, and understanding it sets you apart in interviews.

Strong consistency means a write is not acknowledged until all nodes agree on the new value. Any subsequent read, from any node, will see that value.

This is the safest model but it adds latency, because the coordinator must wait for acknowledgements from every node before returning.

Eventual consistency means writes are accepted immediately and propagated to other nodes in the background. All nodes will converge to the same value eventually, but reads in the interim may return stale data.

Read-your-writes consistency is a middle ground. A user always sees their own most recent write, but may see stale data written by others. This is the minimum acceptable model for most user-facing features.

Choosing the right model is a business decision as much as a technical one. A bank balance requires strong consistency. Showing the wrong balance, even briefly, is unacceptable.

A social media like counter, on the other hand, can tolerate eventual consistency. Seeing 1,042 likes instead of 1,043 for a few seconds causes no real harm.

##Tradeoffs

When a network partition occurs, your system must choose one of two behaviours.

CP systems reject writes (or reads) until the partition heals. The system returns an error rather than risk serving inconsistent data. HBase and Google Spanner are examples.

This is the right choice for financial transactions, inventory counts, and anywhere stale data causes real damage.

AP systems accept writes during a partition and reconcile conflicts afterwards. Each partition continues serving requests independently. Cassandra and CouchDB work this way.

This suits systems where uptime matters more than perfect accuracy, such as shopping carts, analytics, and content delivery.

It is also worth knowing that even when there is no partition, you face a latency-consistency tradeoff.

The PACELC model extends CAP to capture this: during a Partition choose C or A; Else (when running normally) choose Latency or Consistency.

##How It Comes Up in Interviews

Interviewers rarely ask you to define CAP verbatim. They present a scenario and expect you to reason through it.

Can a distributed system be both consistent and available?

Yes, but only when there is no network partition. During a partition you must choose one. Since partitions are unavoidable in practice, every real distributed system is either CP or AP under failure conditions.

What is the difference between strong and eventual consistency?

Strong consistency means a read always returns the latest write, from any node, at the cost of latency. Eventual consistency means a write is accepted quickly and all nodes converge over time, but reads may temporarily return stale data.

Is CAP a one-time architectural choice?

No. Many systems let you tune consistency per operation. Cassandra, for example, lets you set the consistency level on each read and write. You might use quorum reads for critical data and ONE for high-throughput analytics.

Where does CAP show up in a real design?

Almost everywhere. Designing a distributed cache? Choosing between a strongly consistent cache that blocks on writes (CP) and an eventually consistent, gossip-based one (AP) is a CAP decision.

Building a checkout service? You likely want CP. Building a product recommendation engine? AP with eventual consistency is probably fine.

##What’s Next

Now that you understand the consistency tradeoff, these articles cover the mechanisms that implement it in practice.

• Database Replication Explained - how primary-replica and multi-primary replication maps directly onto CP and AP choices.
• Database Sharding and Partitioning - partitioning data across nodes and what it means for consistency.
• Designing a REST API - how your API contract must account for the consistency model underneath it.

##Frequently Asked Questions

###What does CAP theorem stand for?

CAP stands for Consistency, Availability, and Partition tolerance. The theorem states that a distributed data store cannot guarantee all three at once: during a network partition it must choose between consistency and availability.

###Why can’t you have all three CAP guarantees?

Because network partitions are unavoidable in distributed systems. During a partition, nodes cannot communicate.

If you want every node to return consistent data (C), you must refuse requests until the partition heals, which means giving up availability (A). You cannot do both simultaneously.

###Is eventual consistency bad?

Not inherently. Eventual consistency is a deliberate tradeoff that buys lower latency and higher availability. It is the right choice for many workloads, such as social feeds, counters, and caches.

It becomes a problem only when your application cannot tolerate temporarily stale reads, as in financial or inventory systems.

###What is PACELC?

PACELC is an extension of CAP proposed by Daniel Abadi. It observes that even when there is no partition, distributed systems face a tradeoff between Latency and Consistency.

The full model reads: during a Partition choose between Consistency and Availability; Else choose between Latency and Consistency. It gives a more complete picture than CAP alone.