The Vanishing Order
The order is in the database. The confirmation page is reading a copy that doesn’t have it yet.
Customer submits the order. The write lands on the primary.
Where this shows up
Why the read replica gets it wrong
A replica gets each write a little after the primary does. When traffic is light you’d barely notice. Under load the gap grows, and a read that closely follows a write can miss it. To the app, “this order doesn’t exist” and “this order hasn’t reached the replica” look identical.
By the time the decision ran, its context was outdated. We call that a context gap.
Read the order from where it was written.
When orders and holds are written to Tacnode, the very next read sees them. The confirmation page and the duplicate check both read from the place the order went, so there’s no replica to wait on and the second tap is recognized as a retry.
If an engineer asks how
State written to Tacnode is ACID: a read reflects every committed write. Scale-out nodegroups share the same storage, so adding read capacity does not add lag of its own.
Questions to put to your team
- Which screens read from a replica straight after a write?
- How does your app tell “not found” apart from “not there yet”?
- How many duplicate charges did you refund last quarter?
Is your checkout flow telling this lie?
Bring it to a demo, and we’ll trace what it reads and how old that data is by the time it runs.
Book a demo →