📱 Introduction: The Instagram Post
Imagine you are sitting next to a friend at a coffee shop, and you post a photo of your latte to Instagram:
- Strong Consistency (Instant Sync): The moment you tap "Post", the image is saved to all servers instantly. If your friend refreshes their screen a millisecond later, they see your photo immediately. Both of you see the exact same view of the world.
- Eventual Consistency (Delayed Sync): You tap "Post". The image is saved on the local California server, but it takes 10 seconds to replicate to the London server where your friend's account is routed. If your friend refreshes immediately, they see nothing. If they wait 10 seconds, the photo eventually appears.
In distributed databases, Consistency Models define the rules for when and how different nodes in your system see updates to data.
🏗️ Types of Consistency Models
Distributed databases use different rules depending on performance requirements:
STRONG CONSISTENCY (Atomic Sync)
Tx 1 Write "A" ---> [Node 1] --(Blocks Reads)---> [Node 2] ---> Success
Tx 2 Read [Node 1] -------------------> Returns "A"
EVENTUAL CONSISTENCY (Lazy Sync)
Tx 1 Write "A" ---> [Node 1] ---------------------------------> Success
|
+---(Syncs in background)---> [Node 2]
Tx 2 Read [Node 2] -> Returns "Old Val" (Lag)
1. Strong Consistency (Linearizability)
All read operations are guaranteed to return the value of the most recent write, regardless of which database node is queried.
- Tradeoff: High latency. All writes must lock reads across all nodes during sync.
2. Eventual Consistency
Replication logs are copied in the background. If no new updates are made, all replicas will eventually sync up and return identical values.
- Tradeoff: Blazing-fast write speeds, but readers will occasionally see stale data.
3. Causal Consistency
Guarantees that operations that are causally related (e.g. a reply to a message) will be seen in the same correct order by all readers.
- Example: You cannot see the comment reply before the main comment is visible.
💻 Code Examples: Simulating Read-After-Write
Let's simulate how eventual consistency displays delayed data updates.
Multi-Language Execution
⚠️ Common Mistakes
1. Assuming Eventual Consistency is instant
Writing code that depends on immediate consistency (like checking account balance directly from a replica node immediately after a withdraw action). The user can over-draw because the replica shows outdated cash totals.
2. Ignoring Causal Consistency in Message Apps
Allowing comment replies to display on the screen before the main message has synced, making chat rooms look completely disorganized.
🔍 Interview Corner
Q1: What is "Eventual Consistency"?
Eventual Consistency is a weak consistency model in distributed systems where replicas receive background updates. If no further writes are made, all replicas will eventually synchronize and return the identical data value, trading temporary data staleness for low latency.
Q2: What is Causal Consistency?
Causal Consistency is a consistency model that guarantees that operations that are causally related (e.g., a question followed by an answer) are seen in the same order by all nodes in the system. Operations that are not causally related are evaluated concurrently.
📝 Summary
- Consistency Models define how nodes see updates in a distributed system.
- Strong Consistency guarantees instant synchronization but is slow.
- Eventual Consistency enables fast writes but allows temporary reading of stale data.