🔹 1. Consistency Models

What?

Consistency in distributed systems is about what guarantees a read has after a write.

Imagine: you update your Instagram bio → should all friends see it immediately? Or is it okay if some see the old one for a few seconds?

Types of Consistency:

1. Strong Consistency
   • Every read reflects the most recent write.
   • Example: Google Spanner, traditional RDBMS with synchronous replication.
   • Analogy: Updating your WhatsApp status → everyone instantly sees the new status.
2. Eventual Consistency
   • Updates propagate, but not immediately. Eventually all replicas become consistent.
   • Example: Amazon DynamoDB, Cassandra.
   • Analogy: Changing profile picture on Facebook → some friends still see the old one for a few seconds.
3. Causal Consistency
   • If one action happens before another, all nodes must respect that order.
   • Example: Messaging apps (you can’t see “read” before “sent”).
4. Read-after-Write (Session Consistency)
   • User immediately sees their own updates, but others may not.
   • Example: Instagram shows your new profile pic immediately to you, but others may take time.
5. Monotonic Reads
   • If you’ve seen newer data once, you won’t ever see older data later.

Real-World Mapping:

• Banking → Strong Consistency.
• Social Media Feed → Eventual Consistency.
• Chat apps → Causal/Session Consistency.

Interview Hook:

“When asked to design a distributed system, don’t say ‘just consistent.’ Always specify which consistency model you’re targeting based on business needs.”

📌 Image Ref: Consistency Models Diagram