Consistency is about whether everyone sees the same data at the same time. The moment you replicate data across multiple machines (which you must, for availability and scale), those copies can disagree for a while. How you handle that disagreement is one of the deepest topics in system design, and the CAP theorem is the framework interviewers expect you to reason with.
The CAP Theorem
CAP says that when a network partition happens (some nodes cannot talk to others, which is unavoidable in a distributed system), you must choose between two behaviors:
- CP (consistency over availability): refuse or block requests that cannot be made consistent, so no one reads stale or conflicting data. The system may reject writes during the partition. Examples: systems built on consensus like ZooKeeper and etcd, and strongly consistent databases like HBase and Spanner.
- AP (availability over consistency): keep serving on both sides of the partition and let the copies diverge, then reconcile once the partition heals. Reads may be stale. Examples: Cassandra and DynamoDB in their default modes, and a shopping cart that would rather accept an edit than reject it.
The often-listed third option, CA, is not a real choice in a distributed system, because partitions will happen whether you plan for them or not. So the practical question is always: during a partition, do I lean CP or AP?
A Crucial Nuance: PACELC
CAP only describes behavior during a partition. PACELC completes the picture: if there is a Partition, choose Availability or Consistency; Else (normal operation), choose between Latency and Consistency. In other words, even with a healthy network, stronger consistency costs latency, because you must coordinate across replicas before answering. This is the tradeoff you are actually tuning most of the time.
The Consistency Spectrum
Consistency is not on or off; it is a spectrum from strong to eventual.
- Strong consistency (linearizable): every read returns the most recent write, as if there were a single copy. Simplest to reason about, but costs latency and availability because it needs coordination (a quorum or consensus).
- Causal and session guarantees: middle ground such as read-your-own-writes (you always see your own updates) and monotonic reads (you never see time go backward). Often good enough and much cheaper than full strong consistency.
- Eventual consistency: if writes stop, all replicas eventually converge, but a read right now might be stale. This buys the highest availability and lowest latency, at the cost of temporary disagreement and reconciliation complexity.
How It Is Achieved
- Single-leader replication: all writes go to a leader. Reading from the leader is strongly consistent; reading from a follower replica is eventually consistent (and faster).
- Quorums: with N replicas, require W nodes to acknowledge a write and R nodes to serve a read. If W plus R is greater than N, a read is guaranteed to see the latest write. Tuning W and R slides you along the spectrum.
- Consensus protocols (Paxos, Raft): keep a replicated log in agreement for strong consistency, at the cost of coordination latency.
- Conflict resolution for AP systems: version vectors, last-write-wins, or CRDTs (data types that merge automatically without conflicts).
How to Reason in the Interview
Decide consistency per type of data, not once for the whole system. Ask: what breaks if a user sees stale data for a few seconds? For money, inventory counts, and uniqueness constraints, choose strong consistency (CP). For likes, view counts, feeds, and recommendations, eventual consistency (AP) is perfectly fine and gives you better availability and latency. Stating this split is a strong signal.
Common Mistakes
- Claiming strong consistency across regions for free, ignoring the latency cost.
- Using eventual consistency for money or inventory, where staleness causes real bugs like double-spends.
- Saying you will build a "CA system", which misunderstands CAP.
- Confusing CAP consistency (replicas agreeing) with the C in ACID (a transaction leaving the database in a valid state). They are different ideas.
Interview Soundbite
"I will decide consistency per data type. Payments and inventory need strong consistency, so those go through a single-leader store with quorum writes and reads from the leader, accepting the extra latency. Feeds, likes, and view counts can be eventually consistent, so I will serve those from replicas for lower latency and higher availability. During a partition, the money path chooses consistency and the social path chooses availability."