The Profile That Saved and Then Un-Saved Itself
Read what each party saw, commit to a cause, and only then find out which of them was right. The root cause, why the obvious reading was wrong, and the fixes are all held back until you have answered.
The symptom
What was reported, before anyone knew what was happening.
What each party saw, and what each concluded
The evidence, in the form it actually arrived in — several parties, several partial views, several confident conclusions.
| Who | What they could actually see | What they concluded | Verdict |
|---|---|---|---|
| The user | A success confirmation, then the old name on the next screen. | The save silently failed. | ✕ wrong |
| Write path (API server, primary DB) | UPDATE users SET display_name = ... committed, one row affected, 12ms. | The write is durable and visible. Return 200. | ✓ right |
| Read path (a different API server, read replica) | A SELECT returning the previous display name from a replica that was 380ms behind the primary. | This is the current value of the row. | ✕ wrong |
| On-call engineer | Replication lag dashboard: mean 40ms, p99 120ms, well inside the 500ms alert threshold. No alerts fired. | Replication is healthy, so lag is not the cause. | ✕ wrong |
3 of 4 parties reasoned correctly from what they could see and still reached the wrong conclusion. Nobody in this table is careless. Each one acted on complete-looking local information, and the information was local. That gap — between what a node can observe and what is true — is the whole domain, and one of these readings will usually be yours.
Commit before you read on
Replication lag never exceeded 400ms, and the user’s redirect took over a second. Commit to an answer before reading on: how did a 380ms lag produce a stale read a full second after the write?
Write it down even if you are unsure. An unwritten guess quietly becomes “that is what I thought” the moment you read the answer.