CAP Theorem

Consistency vs availability under partition, and how to pick per feature.

The CAP theorem says that a distributed data store can provide at most two of three guarantees at the same time: Consistency, Availability and Partition tolerance. In practice, it's a tool for one decision you'll make in almost every interview: *when the network misbehaves, should this part of the system favor correctness or uptime?*

The three properties

Consistency — every read sees the most recent write (or an error). All nodes agree.
Availability — every request gets a non-error response, even if it may not reflect the latest write.
Partition tolerance — the system keeps working when network failures split nodes into groups that can't talk to each other.

Why it's really "C or A"

Network partitions happen in any real distributed system, so partition tolerance isn't optional. The real choice is what happens *during* a partition:

CP: refuse requests that can't be guaranteed consistent. Some users see errors or timeouts.
AP: keep serving requests from whatever nodes are reachable. Some users see stale data, and conflicting writes must be reconciled later.

Choosing per feature

Systems aren't uniformly CP or AP; individual features are.

[!INTERVIEW] State it in your non-functional requirements "The system should prioritize consistency for seat booking — we can't sell a seat twice — but availability for browsing events and viewing details." This sets up your design choices for the rest of the interview.

What each choice implies for your design

Favoring consistency:

Single primary database with synchronous replication, or a consensus-based store
Distributed transactions or locks where needed
Relational databases (PostgreSQL), or strongly consistent modes of NoSQL stores (e.g. DynamoDB strongly consistent reads)

Favoring availability:

Multiple replicas accepting reads (and possibly writes) independently
Asynchronous replication, eventual consistency
Cassandra, DynamoDB default reads, caches and CDNs
A conflict resolution strategy (last-write-wins, CRDTs, application-level merges)

Beyond CAP: PACELC

CAP only describes behavior during a partition. PACELC adds: *Else* (when the network is fine), you trade Latency against Consistency. Synchronous replication across regions is consistent but slow; asynchronous replication is fast but briefly inconsistent. Mentioning this shows depth when discussing multi-region designs.

Consistency levels in between

"Eventual" and "strong" aren't the only options:

Read-your-writes — a user always sees their own updates (route their reads to the primary briefly after a write)
Monotonic reads — a user never sees data go "backwards" (pin them to one replica)
Causal consistency — effects are seen after their causes (a reply after the message it answers)

These weaker guarantees often give users what they actually need at much lower cost than full strong consistency.