TLDR: Consistency is about whether all nodes in a distributed system show the same data at the same time. Strong consistency gives correctness but costs latency. Eventual consistency gives speed but requires tolerance for briefly stale reads. Choose deliberately — not accidentally.

---

📖 The Shared Paper Calendar

Alice and Bob share a paper calendar on the office wall. There's only one calendar — when Alice writes "Meeting 2pm Monday," Bob immediately sees it. That is strong consistency — one copy, always in sync.

Now imagine Alice and Bob each have their own weekly planner. They sync them once a day. If Alice books 2pm Monday morning and Bob checks his planner at noon, he might not see the booking yet. Eventual consistency — both will agree by end of day, but there is a window of divergence.

Distributed databases face this exact tension at microsecond timescales.

---

🔢 The Consistency Spectrum

From strictest to most relaxed:

Analogy-to-model mapping:

• Alice and Bob on a single wall calendar → Linearizability.
• Two separate planners synced each morning → Eventual.

---

⚙️ Quorum Reads and Writes: The Knob

Distributed systems like Cassandra and Dynamo use quorums to tune consistency vs. availability:

$$R + W > N \Rightarrow \text{Strong Consistency}$$

Where:

• N = total replicas (replication factor, e.g., 3)
• W = nodes that must acknowledge a write before it's considered complete
• R = nodes that must respond to a read

N = 3 walkthrough:

The reason R+W > N guarantees strong consistency: at least one node in the read quorum must have received the most recent write.

---

🧠 Eventual Consistency in Practice: Conflict Resolution

When two clients write to different replicas simultaneously, a write conflict occurs. Resolution strategies:

Shopping cart example (Dynamo): Two offline clients both add items. On sync, both versions are kept as siblings. The application merges them: union of items in both carts. No data loss.

---

⚖️ CAP Theorem: Why You Can't Have Everything

In the presence of a network partition (P), you must choose:

• CP: Stay consistent, stop accepting writes (etcd, ZooKeeper, HBase).
• AP: Stay available, accept stale reads (Cassandra, DynamoDB, CouchDB).
• CA: Impossible in distributed systems — you can't guarantee both without sacrificing partition tolerance.

flowchart TD
    CAP["Network Partition Occurs"] --> CP["CP Systems\nReturn error or stale on writes\nUntil partition heals"]
    CAP --> AP["AP Systems\nReturn available (possibly stale) data\nResolve on partition heal"]

Real-world nuance: Modern systems (e.g., Spanner, CockroachDB) minimize partition probability with high-bandwidth, low-latency network infrastructure and achieve "effectively CA" in practice — but not mathematically CA.

---

📌 Summary

• Linearizability = strongest; one global order. Eventual = weakest; converges to agreement.
• Quorum formula R+W > N guarantees strong consistency from an eventually-consistent store.
• LWW is simple but vulnerable to clock skew; CRDTs are safe for specific types; application merge is most flexible.
• CAP theorem: Pick CP (safety) or AP (availability) when a partition occurs — not both.
• Most real systems choose tunable consistency: default to eventual, escalate to quorum reads for critical data.

---

📝 Practice Quiz

1. A Cassandra cluster has N=3 replicas. You configure W=2, R=2. Is this strong consistency?

   • A) No — only W=3 guarantees strong consistency.
   • B) Yes — R+W = 4 > N = 3, so every read will include at least one replica that received the latest write.
   • C) Depends on network latency.
     Answer: B

2. Two clients update the same DynamoDB item offline. The item now has two conflicting versions when they reconnect. What is the "Dynamo-style" resolution approach?

   • A) The server automatically picks the higher-value version.
   • B) Both sibling versions are returned to the client, which decides how to merge them (e.g., union for a cart).
   • C) The first write is discarded (Last Write Wins).
     Answer: B

3. A distributed service must not return stale data under any circumstances for compliance reasons. Which system characteristic matches this requirement?

   • A) AP (highly available) system with eventual consistency.
   • B) CP (consistent) system with linearizable reads — it may refuse requests during a partition but never returns stale data.
   • C) Any system with a short TTL cache in front.
     Answer: B

---