Day 45: Replication models; CAP and PACELC

Replication models

Single-leader replication: one node accepts writes, replicates to followers — simple, but the leader is a bottleneck and single point of failure until a new one is elected. Multi-leader: multiple nodes accept writes independently, replicating to each other — better write availability, but now conflicting concurrent writes must be reconciled. Leaderless: any node can accept a write, and reads/writes use quorums to stay consistent (Cassandra/DynamoDB-style) — high availability, more complex conflict resolution.

Strong vs eventual consistency

Strong consistency: after a write completes, every subsequent read (from any node) sees it — simple to reason about, but requires coordination that costs latency and availability. Eventual consistency: replicas will converge to the same value *eventually*, but a read right after a write might return stale data — better availability and latency, harder to reason about correctness.

CAP, in plain words

During a network partition (P — which will eventually happen; it's not optional), you must choose: Consistency (refuse requests you can't guarantee are correct) or Availability (keep answering, even if some answers might be stale/wrong). You cannot have both during the partition — this is the actual content of CAP, which is often garbled into the meaningless "pick 2 of 3" (you don't get to choose whether P happens; you only choose C or A when it does).

PACELC: the more useful extension

PACELC says: even when there's no partition, you still trade off Latency vs Consistency — because strong consistency requires waiting for replicas to confirm, costing latency. So the full statement is: if Partitioned, choose Availability or Consistency; Else, choose Latency or Consistency. This is the version that actually informs real database configuration choices (e.g., how many replicas must ack a write before it's considered durable).