Consistency Models — CAP, PACELC, strong vs eventual
Distributed systems must pick their consistency guarantees. CAP is the headline; the real design lives in eventual, causal, and read-your-writes nuances.
**** (Brewer, 2000): a distributed system can guarantee at most 2 of {Consistency, Availability, Partition-tolerance}. Since network partitions WILL happen in production, you effectively choose: **CP** (stay consistent, refuse requests during partition) or **AP** (stay available, accept that different replicas might see different data temporarily).
****: every read sees the latest committed write. Single-master SQL with synchronous replication, Spanner. Convenient programming model — no surprises — but slower and can't always stay available.
****: if writes stop, all replicas converge to the same state eventually. Cassandra, DynamoDB (default), Redis replica. Fast, highly available, but your read can return a stale value.
In between: read-your-writes (a user sees their own writes immediately — others might lag), monotonic reads (once you saw version N, you never see an older version), causal consistency (writes causally related arrive in order; unrelated writes can reorder).
**CAP is a simplification**. **** extends it: on a **P**artition, choose **A** or **C**; **E**lse, choose **L**atency or **C**onsistency. Even without partitions, strong consistency costs latency (replica sync).
Real-world examples: Banking transfer → strong (nobody wants eventual consistency on their balance). Twitter timeline → eventual (no one dies if a tweet appears 1s later). User preferences → read-your-writes (you update, you expect to see the new value; others can lag).
Grounded on https://www.mongodb.com/docs/manual/reference/read-concern/
Next up
Observability — logs, metrics, traces, SLOs
The three pillars (logs, metrics, traces) tell you WHAT broke. SLIs/SLOs tell you if it MATTERS. You need both.