Consistency vs Availability

The Core Tension

When replicas can’t talk to each other (network partition, node death), a write must choose:

 PARTITION BETWEEN REPLICAS

 choose CONSISTENCY:                choose AVAILABILITY:
 refuse the write until             accept the write locally;
 quorum/leader reachable            sync it when healed
 
 users see: errors,                 users see: success now,
 "try again"                        possibly stale/conflicting
                                    reads elsewhere later

CAP names this fork; engineering lives in how deliberately each system chooses per data type. (The theorem’s formal shape — and its common misreadings — get their own lesson in the distributed section.)

Neither Extreme Is Livable

 FULL CONSISTENCY ALWAYS          FULL AVAILABILITY ALWAYS
 every read hits leader           every replica accepts writes
 cross-region writes wait         conflict resolution machinery,
 for the farthest replica         divergence windows everywhere
 +100–200ms on every write        shopping carts showing other
 checkout latency = physics       people's sessions ✗
 
 both collapse under their own extremes → the design question is WHERE ON THE SPECTRUM PER DATA TYPE

The Per-Data-Type Matrix

The mature pattern — no single choice for the whole system:

Data	Choice	Rationale
Payment capture	Consistency, absolutely	Double-charge worse than retry
Trip record existence	Consistency	A trip can’t half-exist
Ride locations	Availability, heavily	Stale position fine; blocked match isn’t
Feed/timeline	Availability	Seconds of staleness invisible
Session/token validity	Leans availability with short TTLs	Login outage shouldn’t log everyone out

Each row is an architecture decision already made — storage engine, replication mode, and failure behavior follow from it.

The Middle Ground Machinery

Between the extremes sits tunable tooling:

 quorum reads/writes (W+R > N)     → consistency dial by config
 leader-follower w/ sync or async  → durability vs latency dial
 read-your-writes via session      → user-perceived consistency cheaply
 last-write-wins / CRDTs           → availability with bounded weirdness
 
 most production stores expose these dials (Cassandra, DynamoDB-
 family, Cosmos); choosing settings per table IS this trade made real

User-Perceived Consistency Tricks

Much of the felt tension dissolves with session-level guarantees rather than global ones:

 - after posting, route THAT USER's reads to the primary briefly
   (read-your-writes) — everyone else keeps reading replicas fast
 - monotonic reads: pin a user's session to one replica so time
   doesn't appear to run backwards mid-scroll
 
 cost: tiny routing logic. benefit: strong FEELING without global cost.

Interview Framing

Interviewers test whether candidates treat this as a slogan (“we pick AP”) or as engineering. Scoring shape: walk the data inventory and assign per-type choices with reasons (“payments block on consensus; positions never do”), then name the mechanism implementing each row. The follow-up “what does the user actually see during a partition?” separates memorized CAP from designed behavior.