Discussion on "System Design Drill Day 4: Read Replicas and Replication Lag"

Anish Ansari · 2026-10-22T03:13:10.626Z

A customer places an order, gets redirected to "My Orders", and the list is empty. They refresh and the order appears. Anyone who has added read replicas to a busy app will recognise that support tick

One caution on the session-based pin: keep it narrow. Pinning every read for a few seconds after any write sends the whole dashboard to the primary, including the heavy catalog queries the replicas exist to serve. I pin only the read-your-writes route itself, My Orders in this case, and leave everything else on the replica. Lag protection only earns its cost where a stale row actually breaks the flow.

Fair point Kamran, pinning only the route that actually needs read-your-writes is the better default. Pin everything and you've just moved the catalog load back onto the primary, which is the problem the replicas were there to solve.

The empty My Orders page right after checkout is the textbook read-your-writes failure. Sending the reads that follow a write to the primary for a short window is usually cheaper than making the whole app strongly consistent.

Thanks Abhinav, that empty My Orders page is exactly the bug that makes people think their order failed. Pinning reads to the primary for a few seconds after a write fixes it without paying for strong consistency everywhere.

Search Hashnode

System Design Drill Day 4: Read Replicas and Replication Lag

Responses4