Why Your New Master‑Slave DB May Not Reflect Recent Writes—and How to Fix It

Introduction

When I first joined the company I faced a problem with a database read‑write separation architecture: newly added mapping rules did not take effect immediately, and queries returned no data.

The issue was caused by the master‑slave setup where writes go to the master and reads go to the slave, which lags behind due to replication delay.

Database Architecture Evolution

Primary‑Backup (Master‑Standby)

Initially a single database is used, but it has a single point of failure. Adding a standby replica that synchronously mirrors the master solves availability but only activates on failure.

When the primary fails, the standby can be promoted manually to become the new master.

Master‑Slave (Read‑Write Separation)

As traffic grows, reads become a bottleneck. Adding read replicas (slaves) allows the master to handle writes while slaves serve reads, improving read performance. However, asynchronous replication introduces latency, causing temporary inconsistency.

During the latency window, reads from the slave may miss recent writes, which was the root cause of the observed problem.

Solutions to Master‑Slave Lag

1. Tolerate Inconsistency

If the application can accept stale data, no changes are needed.

2. Synchronous Replication

Configure the master‑slave link to be synchronous so the write returns only after the slave has applied the change, at the cost of higher write latency.

3. Force Reads to Master

For strongly consistent operations, route reads to the master, sacrificing some read scalability.

4. Middleware Routing

Introduce a middleware that records recent write keys; reads for those keys are sent to the master, otherwise to the slave.

5. Cache‑Based Routing

Use a cache to store keys of recent writes with an expiration equal to the replication delay; reads check the cache and decide whether to query the master or slave.

Conclusion

Read‑write separation solves read bottlenecks but brings replication delay and temporary inconsistency. Choose the mitigation strategy that best fits your consistency requirements and performance constraints.