TechNovaRead replicas: two production traps nobody warns you about
Adding read replicas is one of the easiest ways to take load off your database. It is also one of the easiest ways to ship bugs that only show up in production. Here are the two I see most often, and how to avoid them.
What a read replica is, in one minute
Your main database, the primary, handles every write. A read replica is a copy that receives those changes and serves read queries. Most apps read far more than they write, so moving reads to replicas lets the primary breathe.
The catch is in one word: copy. Changes reach the replica a little later. Usually milliseconds. Sometimes much more.
Trap 1: “I just saved it, where did it go?”
A user updates their address and clicks save. The write goes to the primary. The page reloads and reads from a replica that hasn’t caught up yet. The old address is back. The user saves again, gets annoyed, and opens a support ticket.
Nothing is broken. The data is correct on the primary. You just read it too early from somewhere else. This is a read-your-own-writes problem.
How to fix it:
- Right after a user writes, send that user’s reads to the primary for a short window, for example a few seconds.
- Send reads that must be fresh (balances, order status, permissions) to the primary, always.
- Return the saved data in the write response, so the page doesn’t need to read it again.
Trap 2: lag grows exactly when you need replicas most
On a quiet day, replication lag is tiny and everything looks fine in testing. Then comes your biggest sale. Writes spike, replicas fall behind by seconds or more, and now a large share of your users see stale stock, stale prices or orders that “don’t exist yet”.
The replicas were supposed to protect you under load. Under load is when they drift the most.
How to fix it:
- Monitor replication lag as a first-class metric, with an alert.
- Take a replica out of rotation when its lag passes a limit you choose, and fall back to the primary.
- Load-test with realistic write traffic, not just reads.
Replicas are great for reads that can be a little old. Decide, for every important read, whether it can be stale. If it can’t, read from the primary.
FAQ
Do read replicas help with write load?
No. Every write still goes to the primary. Replicas only take read traffic.
Is a read replica a backup?
No. A bad delete on the primary is copied to the replica within seconds. Keep real backups.
How many read replicas do I need?
Start with one. Add more when you measure that reads, not slow queries, are the bottleneck.
Read next: The dual-write problem: why your order saves but the event never arrives