Read Your Own Writes

The save can succeed and still look like it vanished.

Writes go to the primary database. Reads may go to replicas that copy the primary a moment later. If the page reloads from a replica before that copy catches up, the user sees the old value and reasonably assumes the save failed.

This pack covers both the disappearing settings save and the duplicate-comment version of the same bug.

The consistency rule

After a successful write, dependent reads for that actor must come from a source at least as fresh as the write.

The simple implementation is a short sticky-primary window:

1. Commit the write on the primary.
2. Store a session marker with the affected data scope and expiry.
3. Route matching reads for that actor to the primary.
4. Remove the marker after measured replica lag plus a safety margin.

A stronger system returns a commit position or consistency token and routes reads to a replica only after it has replayed through that position. Use the simplest mechanism your database and routing layer can prove.

Scope matters. Saving one profile should not send every read from every user to the primary. Tie the marker to the actor, tenant, and affected resource or data boundary. Keep duplicate-submit protection separate; idempotency stops a second action, while read-your-own-writes stops the stale screen that encourages it.

Measure before choosing the window

Record replication lag at normal load, peak load, failover, and maintenance. A hard-coded 200 ms window is only safe if lag cannot exceed it. Alert when observed lag approaches the routing window.

Define primary failure behaviour. You may show a temporary "saved, still syncing" state, wait, or return a clear error. Silently falling back to stale data recreates the lie.

Verification checklist

1. Intentionally delay the replica.
2. Write a new value, then read immediately as the same actor. The new value appears.
3. Read as an unrelated actor. Normal replica routing still works.
4. Wait for catch-up and expiry. The writer returns to replica reads.
5. Submit the same comment twice and prove idempotency handles the duplicate separately.
6. Delete a record and prove it does not reappear from a lagging replica.
7. Make the primary unavailable and verify the documented degraded behaviour.

The starter takes write events, a lag threshold, session-routing policy, failover rules, and delayed-read fixtures. It returns the consistency-token contract, sticky-primary window, expiry, failover behaviour, telemetry, and deterministic replica tests. Dry-run changes no database.

Download the runnable pack

• Complete workflow pack ZIP
• Importable n8n workflow
• GitHub validation workflow
• GitHub manual run workflow
• Docker Compose file
• Fictional sample payload
• Expected safe dry-run result

Use EVENTUAL for the save-button case and REPLICA for the comment/read-replica case.