The setting that saved, then didn't
Reads were moved to a replica and the database load halved. Then support started getting a strange report: a user changes their display name, the page reloads, and the old name is back. Refresh again and the new one appears.
Nothing is broken. Replication is asynchronous, and the read landed on a replica that hadn't caught up yet.
Boundaries, outermost first: Database cluster: Primary (accepts writes), Read replica (lags behind; FAILED: behind) Outside every boundary: App (reads and writes), an empty slot for the where writes must go, an empty slot for the reload right after saving, an empty slot for the monthly report Connections: App calls where writes must go (step 1) where writes must go calls Primary App calls reload right after saving (step 2) App calls monthly report (step 3) monthly report calls Read replica Primary publishes to Read replica — async replication · lag