In a distributed system with multiple replicas, "Consistency" refers to how and when all nodes see the same data after an update.

Strong Consistency (The Master Key)

Think of a Facebook Status Update:

• You post a status.
• Strong Consistency means no one on Earth can see your profile until every single server in every country has saved your post.
• It's 100% accurate, but it's very slow to post!

Eventual Consistency (The Viral Rumor)

Think of a Celebrity Tweet:

• A celebrity tweets.
• Some people see it instantly.
• Some people see it 5 seconds later.
• But Eventually, everyone sees it.
• It's incredibly fast, but for a few seconds, people might have different versions of the "truth."

---

1. Strong Consistency

• Rule: A read is guaranteed to return the most recent write.
• Used by: Financial systems, Inventory tracking.
• Trade-off: High Latency, Low Availability during network partitions (CAP Theorem).

2. Eventual Consistency

• Rule: If no new updates are made, eventually all accesses will return the last updated value.
• Used by: Social media feeds, Comment sections, DNS.
• Trade-off: Low Latency, High Availability.

3. Read-Your-Writes Consistency

A middle ground where a user is guaranteed to see their own update immediately, even if other users don't see it yet.

---

CAP Theorem Connection

Consistency models are the "C" in CAP. Remember: You can't have Strong Consistency and High Availability if the network breaks (Partition). You must choose.

Use Case Questions

• "Which model would you use for a Bank?" (Strong).
• "Which model would you use for a LIKE count on Instagram?" (Eventual).
• "Is eventual consistency 'bad'?" (No! It's the secret to how the internet scales to billions of users).

Key Term: "Quorum"

To achieve the balance you want, you can tune the Read (R) and Write (W) factors.

• If $W + R > N$ (number of nodes), you have Strong Consistency.
• This is how systems like Cassandra allow you to choose your consistency level per query. 🌐