Replication lag & read-your-writes
Ledger's members add an expense, refresh — and it's gone, then back. The replicas are a little behind. How stale do reads get as lag grows, how do you make sure people always see their own changes, and what does waiting for a replica cost?
15 minMediumStation: Replication lag & read-your-writesMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Access patterns & denormalization
- Read replicas
- Replication lag & read-your-writes
- Read your own writes
What you'll be able to do
- 1Predict when a read sent to a replica returns stale data, and how the share of stale reads changes as write load and lag grow.
- 2Choose a routing rule — always primary, primary for a window after a write, or replica once caught up — that gives read-your-writes for the reads that need it while keeping most reads on replicas.
- 3Explain what synchronous replication buys and costs compared with asynchronous — commit latency against losing the newest writes when the primary fails.
Inside the lesson
- steps
- 13
- questions
- 11
- simulations
- 4
You guess first, then run the system and see if you were right.
Step 1 · The setup
Ledger grew, so its group pages now read from two read replicas while every new expense is written to the primary. It's Sunday evening: about 300 members are logging the weekend's receipts — one every 10 seconds or so — with their group page open and refreshing live, about twice a second. That's 600 page loads a second. Each page now loads the group's expenses and balances, about 15 ms in the database.
Then the support tickets start: "I added the dinner, refreshed — it was gone. A second later it was back."
Steps 2–13 are for members