RDS Scaling Patterns: When Read Replicas Become Your New Problem

Read replicas solve one scaling problem.

Then quietly create another.

We saw this in a Rails SaaS system running on AWS RDS.

As traffic increased, adding read replicas looked like the obvious scaling decision.

Initially, it worked well:

* Primary DB load reduced
* Read performance improved
* APIs became faster under traffic spikes

But after some time, new issues started appearing.

Not in writes.
In consistency.

Some users were seeing:

* Recently updated data missing for a few seconds
* Different results across screens
* Background jobs reading stale records

The problem was replication delay between primary and replicas.

One reporting workflow even generated incorrect summaries during peak traffic because reads were happening before replica sync completed.

That was the turning point.

We changed the architecture approach:

* Critical user flows always read from primary DB
* Replicas handled reporting and analytics queries only
* Background jobs were separated based on consistency needs
* Added monitoring specifically for replication lag

After that:

* User-facing inconsistencies reduced significantly
* Reporting became more predictable
* Production debugging became easier

Important learning:

Scaling reads is easy.

Managing consistency after scaling is where architecture decisions matter.