CAP Theorem in System Design

CAP is not a trivia card. In a distributed system, partition tolerance is already spent. The interview is: if a replica cannot see the latest write, do you error, or do you serve stale? That answer decides the rest of the design.

This note follows Hello Interview. Seat inventory that cannot double-sell is Building an Event-Driven Ticketing Backend. Where strong consistency lives on this stack is Data Modeling in System Design. Stale replicas and CDC are Caching in System Design and Message Queues in System Design. This note is the trade.

Pattern Map

1. What CAP actually says

You get two of three. Reciting that is not the interview.

• Consistency means every user sees the same data at the same time. In this context that is strong consistency: every read reflects the latest write.
• Availability means every request gets a response — success or not. The response may be stale. It still has to exist.
• Partition tolerance means the system still works when nodes cannot talk to each other. A dropped link, a dead AZ, a replica that has not heard the write.

Failure: treating CAP as "pick any two" and offering a CA system. A distributed interview system already has partitions. CA is a single box.

2. Why P is not a choice

Non-functional requirements start here. Align on features, then on qualities. The first quality question is CAP.

• Almost every system design interview is a distributed system. Nodes, replicas, regions. Networks fail between them. P is already spent.
• What remains is C versus A. Does this product need every user to see the same state at the same time, or can a request keep answering with data that might be wrong for a while?
• That choice is not decoration. It decides whether you get a single writer, replicas, CDC, higher latency, or an error instead of a page.

Failure: listing "highly available and strongly consistent" in the NFRs and never saying which one you drop when the replica is dark.

3. The partition

Two servers. One in the USA, one in Europe. User A updates a public profile name on the USA box. The write is supposed to replicate. Then the link dies before Europe has the new name. User B reads from Europe.

User A writes name  →  USA
                         |  replicate  →  Europe  →  User B reads
                         ×  partition before replicate
                         |
                         decide: error (CP) or stale name (AP)

• CP. Stop serving. Return an error, or wait until the replica can prove it has the latest write. User B does not see the old name. User B may see nothing.
• AP. Serve the old name. The system stayed up. The data is wrong until the link returns and the replica catches up.
• Those two are at odds because the nodes cannot agree. You cannot both guarantee the latest write and keep answering from a node that has not seen it.

Failure: drawing two regions and never saying what a read does when replication has not finished. That is the whole theorem.

4. When stale is catastrophic (CP)

Ask: if two users saw different state, would the product break in a way you cannot apologize for?

• Tickets. User A takes seat 6A. The partition lands before Europe hears it. User B still sees 6A free and books it. Two people arrive for one seat. The ticketing note is this path — Building an Event-Driven Ticketing Backend.
• Last unit. One toothbrush left. Two checkouts both believe they bought it. Inventory that can oversell is not inventory.
• Money. An order book, a transfer, a stock with a thin float. Stale price or stale balance is not "a few seconds of lag." It is the wrong trade.

If stale would be catastrophic, refuse the read. Consistency over availability.

Failure: showing a spinner that still reads the stale replica, then calling it CP. Waiting only counts if the response cannot lie.

5. When stale is fine (AP)

If stale would not be catastrophic, keep answering. That is most products.

• A profile name that lags for a minute. A social post that Europe has not seen yet. A Yelp listing whose menu item is one revision behind. A Netflix title whose description has not reached every region.
• Availability is the default. You reach for CP when the alternative is two owners of one seat, not because "consistency sounds senior."
• Eventual consistency is still consistency. The system converges. It is not "inconsistent forever." It is "wrong for a bounded window, then right."

Failure: forcing a single-node SQL box onto a feed because you recited CAP and picked C for everything.

6. How the choice shows up in the design

The NFR is a letter. The design is what you actually build.

You chose CP.

• A single writer. One Postgres that issues atomic transactions. Everyone reads the same instance, so there is nothing to propagate. The airline-ticket interview default.
• Distributed transactions when two stores must agree — cache and database, or two services — so a write to one is a write to both. Expensive. Avoid it if one store can own the truth.
• Higher latency. Spinners while replicas catch up, or while a quorum is reached. Google Spanner. DynamoDB strong consistency reads are allowed, not required. NoSQL is not "AP only."

You chose AP.

• Read replicas. Scale out. Propagation lag is the product, not a bug. CDC is eventually consistent by definition — Message Queues in System Design.
• Cassandra. DynamoDB in its default mode, across AZs. A cache that may be wrong — Caching in System Design.
• The user always gets a page. The page may be last minute's page.

Failure: promising CP and then putting a cache-aside Redis in front of the seat row. Or promising AP and blocking every read until the replica is caught up.

7. Different paths, different sides

CAP is per path, not per product. A senior interview names which.

• Ticketmaster. Booking a seat is CP — two users must not own 6A. Creating or updating an event description is AP — better that people can always see the event than that one menu line is exact. Search and browse stay up.
• Tinder. Matching is CP — the second swipe should see that the first already happened, or you do not show "It's a match." Profile photos are AP — last week's picture for a few seconds is fine.
• Say it out loud: availability for search and profile, consistency for the write that assigns a scarce thing.

Failure: stamping the whole architecture CP because the prompt mentioned tickets, then making event search wait on the inventory writer.

8. Consistency is a spectrum

In CAP, "consistency" means strong. Every read reflects the latest write. That is not the only level you can name.

• Strong. All users, same state, now. The CP read. Seat 6A is taken or it is not.
• Causal. Related events stay in order. A reply cannot appear before the comment it replies to. Not everyone has to see every comment yet. Nobody sees the thread inverted.
• Read-your-writes. The user who just saved must see their own update, or they will click again. User B in Europe can still see the old name. The writer cannot. Sticky routing to the primary, or return the written entity in the POST and let the client merge.
• Eventual. AP's floor. Writes stop, replicas converge. The next read is not promised to see the write that just landed.

Name the level on the path, not on the company.

Failure: saying "we're eventually consistent" and then surprising the person who just edited their name. Eventual for Europe. Read-your-writes for the writer.

Recap Q&A