System Design & Architecture Interview Question 2: Read Your Writes Profile
System Design & Architecture Interview Questions · Test 1 · question 2 of 10
A social app sends all writes to a leader database and load-balances reads across several asynchronously replicated followers. Users complain that after they edit their bio and refresh the page, they sometimes see their old bio for a few seconds before the new one appears. It is fine for *other* users to see the change a few seconds late.
Which change fixes the complaint without slowing down writes and without giving up read scaling across the followers?
Show answer and explanation
Answer:
The symptom is replication lag seen by the user who made the write. The guarantee they are missing is read-your-writes consistency: after a process updates an item, it always sees the updated value and never an older one. Other users only need eventual consistency. Option C provides read-your-writes just for the writer. For a short window after their write (or until the followers have caught up to that write's position in the log), that user's reads of their own data go to the leader. Everyone else keeps reading from the followers, so read scaling is preserved and writes are unchanged.
Option A removes the lag, but every write now waits for every follower. That slows writes and makes one slow follower stall all writes. The stem rules out slowing writes.
Option B also works, but it turns the followers into standbys and pushes the entire read load onto the leader, which gives up read scaling.
Option D makes things worse. A 5-minute TTL can serve the old bio for up to five minutes after the edit, which is much longer staleness than the replication lag it was meant to hide.
Reference: Eventually Consistent - Werner Vogels