Why Your App Shows Stale Data Even Though the Write Succeeded

Subtitle: The write was fine. The read never promised to see it.

Left column - Why the stale read happens:

3 replicas hold one row Write returns after 2 acks Read is answered by just 1 That 1 may be the node that missed No error - nobody promised it

Right column - The arithmetic that fixes it:

R + W > N closes the window Overlap means one node saw it Any quorum read hits that node Fresh reads cost more latency Choose per read, not per database

The simple difference:

W=2 R=1 N=3 -> stale read allowed W=2 R=2 N=3 -> stale read closed

Use it when - stale is fine:

likes, view counts, feeds Use it when - must be fresh: balances, stock, locks

Reproduce it in 60 seconds:

Pause one replica Write from client A Read from client B at once

Sticky note - Common beginner mistake:

Read-your-writes is not the same guarantee as eventual consistency. Sticky routing only hides the stale read - it never closes the window.