System design guide
Consistency models, CAP and PACELC for system design interviews
"Is this strongly or eventually consistent?" is one of the most common follow-up questions in design rounds. A good answer picks a model per piece of data, ties it to product requirements, and knows what CAP does and doesn't say.
Consistency models from strongest to weakest
| Model | Guarantee | Typical use |
|---|---|---|
| Linearizable (strong) | Every operation appears to happen at one instant between its start and end; reads always see the latest committed write | Balances, inventory counts, locks, leader election |
| Sequential | All nodes see operations in the same order, consistent with each client's own order | Replicated logs |
| Causal | If one write could have influenced another, everyone sees them in that order; unrelated writes can appear in any order | Comments and replies, chat |
| Read-your-writes | A user always sees their own updates | Profile edits, posting content |
| Monotonic reads | A user never sees data go back in time | Feeds, dashboards |
| Eventual | If writes stop, replicas converge | Like counts, view counts, caches, search indexes |
The middle models (causal, read-your-writes, monotonic reads) are the useful ones interviewers rarely hear about. They give users a sensible experience at much lower cost than strong consistency everywhere.
What CAP actually says
CAP applies to replicated data during a network partition. If replicas can't talk to each other, a request that reaches one side must either:
- Choose consistency (CP): refuse or block the request so no one sees stale or conflicting data, or
- Choose availability (AP): answer anyway, accepting that replicas may diverge and need reconciling later.
Partitions aren't optional in distributed systems, so "CA" isn't a real choice for a multi-node system. And CAP is per operation and per piece of data: one system can be CP for payments and AP for the activity feed.
PACELC: the everyday trade-off
Partitions are rare; latency is constant. PACELC adds: else, when the network is healthy, you trade latency against consistency. Synchronously replicating every write to a quorum or another region before acknowledging adds round trips. That's why many systems default to asynchronous replication and offer stronger reads as an opt-in.
Quorums
With N replicas, writes wait for W acknowledgements and reads query R replicas.
- R + W > N: reads overlap the latest write, giving strong-ish reads (with caveats around concurrent writes and failures).
- N=3, W=2, R=2: tolerates one slow or failed replica for both reads and writes. A common default.
- W=1, R=1: fastest, eventual consistency; conflicts resolved later (last-write-wins, vector clocks, or CRDTs).
- W=N: every replica must acknowledge; one failed replica blocks writes.
Leader-based systems (one primary per shard, with consensus like Raft or Paxos for failover) give linearizable writes through the leader; reading from followers is cheaper but may be stale unless you use leader reads or read leases.
Choosing per piece of data
| Data | Model | Why |
|---|---|---|
| Payment state, ledger, inventory reservations | Strong (CP) | Wrong answers cost money; better to fail a request |
| Usernames, unique constraints | Strong for the uniqueness check | Two users must not claim the same name |
| User's own posts and settings | Read-your-writes | Users notice when their own change "disappears" |
| Chat messages | Causal / per-conversation order | Replies must follow the messages they answer |
| Feeds, counts, recommendations, search | Eventual (AP) | Staleness of seconds is invisible; availability matters more |
Techniques that give "enough" consistency cheaply
- Sticky reads: route a user's reads to the primary (or the replica they wrote to) for a short time after they write.
- Version tokens: return a write's log position to the client; reads wait until the replica has caught up to it.
- Idempotency and conflict-free data types make retries and concurrent updates safe without coordination.
- Outbox and change data capture keep caches and search indexes eventually consistent with the database in commit order.
How to talk about it in an interview
- Name the model for each major piece of data, not one model for the whole system.
- Tie each choice to a product consequence ("a stale like count is harmless; a double-spent balance isn't").
- Say what happens during a partition or replica failure for the critical path.
- Mention the latency cost of stronger guarantees (PACELC), especially across regions.
See these choices applied in design a payment system (strong), design a news feed (eventual), and design a chat app (per-conversation ordering).
FAQ
What does the CAP theorem actually say?
When a network partition separates nodes of a replicated system, each operation must choose between consistency (every read sees the latest write, or an error) and availability (every request gets a non-error response, possibly stale). Without a partition, you can have both. It doesn't mean you pick two of three in general.
What is PACELC?
An extension of CAP: if there is a Partition, choose Availability or Consistency; Else (normal operation), choose Latency or Consistency. It captures the everyday trade-off that strongly consistent replication adds latency even when nothing is broken.
What does R + W > N mean?
In a quorum-replicated store with N replicas, if each write waits for W acknowledgements and each read queries R replicas, then R + W > N guarantees every read overlaps at least one replica that has the latest write. For example N=3, W=2, R=2.