Module 5 · When Copies Disagree · Lesson 21 of 35
What is eventual consistency? When "late" is not "wrong"
12 minFree System design course · Beginner to intermediateLesson 5.2By Saket Bhatnagar
Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.
In short
- What is eventual consistency? It is a promise that if writes stop, every copy of the data will agree, though a read may show an older value until then.
- Late is not wrong. Read-your-writes shows you your own changes at once; strong consistency always gives the latest value.
- Consistency is a ladder: each higher rung costs speed or availability, so you pick a rung per feature.
Video lesson · coming soon
What is eventual consistency? When late is not wrong
Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.
- 01 Seat taken, but the map says free
- 02 The family group chat
- 03 The ladder with price tags
- 04 What you see, what it costs
- 05 Zoya’s label sheet
- 06 Next: when the line is cut
SeatJaldi now runs in two regions: its servers in Mumbai, and a second set in Hyderabad for fans in the south and east. The one-step update from the double-booking fix works: on the primary, only one tap can claim a seat. Arjun tests it on match 42. He taps Book on A12 and gets “Seat taken”. On the seat map, A12 is still green.
He files a bug called “seat map lies”. The same week, Kalpana, a fan in Nagpur, books a ₹299 seat and opens My bookings. It is empty. She writes to Meera in the same words lesson 17’s users did: “My booking disappeared.”
“Let us read everything from the primary,” Arjun says. “Then nothing is ever late.” Zoya asks, “And at noon, when every read lands on that one machine?” Meera asks, “What do I tell users?”
Zoya writes two lines on the whiteboard. The seat map may be about two seconds late. Kalpana’s own list must never be. Why are those two different?
What is eventual consistency?
Eventual consistency means a read may be late, but once writes stop, every copy agrees. That is Arjun’s green A12. With one primary, as at SeatJaldi, the old value is not made up; it was true a moment ago.
It is not the only promise a system can make, and each kind of promise has a name.
Keep one line in your head: consistency is a ladder, and each higher rung costs speed or availability. This lesson uses three rungs.
- Eventual, the bottom rung: any copy answers, fast, and a read may be a little old.
- Read-your-writes, the middle rung: you see your own changes at once; others may see them late.
- Strong, the top rung: every read gets the latest value. It waits on the primary and may refuse to answer when the primary is out of reach.
The consistency ladder with price tags
Drag to exploreThree rungs, cheapest to dearest. Eventual is fast but may be late. Read-your-writes shows your own changes at once. Strong waits on the primary.
Diagram connections:
- Eventual to Read-your-writes (Costs more)
- Read-your-writes to Strong (Costs more)
- Seat map to Eventual (Needs)
- My bookings to Read-your-writes (Needs)
- Claim a seat to Strong (Needs)
- Eventual: Cheapest: any copy answers, and a read may be late.
- Read-your-writes: You see your own changes at once; others may be late.
- Strong: Always the latest value, read from the primary.
- Seat map: Browsing, where two seconds late is fine.
- My bookings: Must show your new booking at once.
- Claim a seat: Sells the seat, so it must be true.
You have seen this when a friend still sees your old profile photo after you changed it. Their phone read a copy that had not got the change yet.
You have seen it when you place an order, tap My orders, and it is empty until you pull to refresh. The list came from a copy that was a second behind.
What is read your writes consistency?
Read-your-writes is lesson 17’s rule for My bookings. In the chat, your own post shows on your phone at once, even if Mausi’s phone is behind.
So why does Kalpana’s booking vanish again? Her phone reaches the Hyderabad servers, which read My bookings from the nearest replica. Lesson 17’s 10-second rule lives only on the Mumbai servers.
Neither is wrong. What differs is whose change it is, and what being late costs.
Arjun sees someone else’s change, and a seat that looks free costs nothing, because the claim on the primary checks again. Kalpana sees her own change after paying ₹299. An empty list looks like lost money.
Strong vs eventual consistency: which does each feature need?
Choose the rung per feature, and pay only where a late answer would cost something. Strong consistency, where every read sees the latest finished write, belongs on steps that sell or spend something limited.
In the chat, strong is phoning Vandana herself before you act on the news. You hear the truth, but it takes a call, and if her phone is off, you wait.
What just happened? The price grows as you climb. Arjun’s idea pays the top price on every screen, even ones that only look.
| Feature | Rung | What the user sees | Price |
|---|---|---|---|
| Seat map | Eventual | A seat may look free for about two seconds | Cheapest: any replica answers |
| My bookings | Read-your-writes | Your own booking is there at once | Some of your reads go to the primary |
| Claim a seat | Strong, on the primary | The answer is always the true one | Slower; refused if the primary is out of reach |
How do you build each rung, and what does it cost?
Experts list many more models than these three, but these three cover most screens you will build. In practice, each rung you use becomes a routing rule: which copy may answer this read? In the chat, it is the question “whose phone do I check?”
- Eventual: any replica answers. The promise never says how long “a while” is, so measure the lag. Assume under a second, against a seat-map budget of about two.
- Read-your-writes: Zoya’s rule from lesson 17. The session store keeps the time of the user’s last write, and for 10 seconds after it their reads go to the primary.
- Strong: read from the primary, which always holds the latest value. It waits for that one machine.
One old rule to drop: a large cloud object store has given strong consistency for reads after writes since 2020. Check your store’s docs, not old advice.
Now price Arjun’s idea. Assume 9 reads for every write, with two replicas taking all the reads. Of every 10 requests, the primary handles the 1 write. Send it every read and it handles 9 + 1 = 10, ten times as many requests.
A sharper read-your-writes remembers where the user’s last write sits in the primary’s change log, the numbered list of changes it sends to replicas. Any replica past that point can answer, which spares the primary. In PostgreSQL it takes two queries.
-- On the primary, after the booking commits.
SELECT pg_current_wal_lsn();
-- -> 0/3A1B2C8 (save it in her session.)
-- On a replica, before reading My bookings.
SELECT pg_last_wal_replay_lsn() >= '0/3A1B2C8'::pg_lsn
AS caught_up;
-- -> true: read here. false or NULL: use the primary.What just happened? The first query gives a position in the primary’s change log just after Kalpana’s booking. The second asks a replica whether it has replayed that far. If yes, her booking is on that copy.
Two traps. Compare positions in SQL, not as text in app code: “0/10000000” sorts before “0/3A1B2C8” as text but is further along. Also, keep synchronous_commit on, the default, so a commit waits until its change is written to disk. With it off, the saved position can land before the booking.
To test it, stop replication in a test setup and click through. Eventual screens may go stale; read-your-writes screens must still show your new booking; claims must stay true.
Try it yourself
Label six features
Give each a rung, and ask what a two-second-old answer would cost. (a) seat map, (b) My bookings right after booking, (c) claim a seat, (d) match description, (e) a one-time coupon, (f) changing your display name. Write your six answers before you read the next step.
Compare
(a) eventual. (b) read-your-writes. (c) strong, or a seat sells twice. (d) eventual. (e) strong, or the coupon is used twice. (f) read-your-writes.
How to know you got it right
You got it right if the steps that sell or spend something limited (c and e) are strong. The screens that only look (a and d) are eventual. The screens showing your own latest change (b and f) are read-your-writes.
The seat map shows other people’s changes, and the claim checks again, so late is fine. My bookings shows Kalpana’s own change, so it must be read-your-writes. It is the family chat again: Mausi may hear the news late, but whoever posted it must see their own post at once.
Zoya pins up the label sheet, and every new screen gets a rung before it ships. The Hyderabad servers get the read-your-writes rule, and Kalpana’s next booking shows at once. Arjun closes his bug: late by design.
Meera has her line for users: “Once you see Confirmed, the seat is yours. The seat map may take a moment to catch up.” SeatJaldi now runs in Mumbai and Hyderabad. What if the link between the two data centres is cut?
Check yourself
Check yourself
Kalpana books a seat, opens My bookings and sees nothing, then refreshes and sees it. What happened?
Pick an answer to see why it is right or wrong.
Check yourself
Which SeatJaldi feature needs the strong rung?
Pick an answer to see why it is right or wrong.
Check yourself
Arjun says, “Read everything from the primary so nothing is ever late.” What does that cost?
Pick an answer to see why it is right or wrong.
Remember these three
- Consistency is a ladder, and each higher rung costs speed or availability.
- Eventual means late, not wrong: pick the rung per feature by asking what a late answer costs.
- Decisions that write or spend something limited read from the primary; replicas are for looking.
Questions people ask
- What is eventual consistency in simple words?
- It means that if nobody changes the data for a while, every copy ends up the same. Meanwhile a read may show an older value. That is fine on a seat map, but not where a stale answer sells something limited.
- What is the difference between strong and eventual consistency?
- Strong consistency always returns the latest value, but it waits on the primary, so it is slower and can refuse. Eventual consistency is fast and keeps answering, but may be a little behind.
- What is read your writes consistency?
- It is a promise that after you save a change, your own next read shows it. Other people may still see the old value for a moment, which is usually harmless.