How to Get Read Replicas and Scaling Reads Right
Copies of a database that serve read queries, reducing load on the primary database.
Marcus Adeyemi
What is at stake
Most web applications read far more than they write, and replicas are a common first scaling step.
The playbook
- Route reporting and heavy reads to replicas
- Read from the primary after writes when consistency matters
- Monitor replication lag
- Test failover procedures
- Document which queries go where
Where it goes wrong
Avoid:
- Sending all reads to replicas blindly
- Ignoring replication lag in user-facing flows
- Unmonitored replicas
- Failover never tested
The numbers behind it
| Measure | Figure |
|---|---|
| Replication lag | replicas can be slightly behind the primary |
| Read-after-write | users may not see their own changes on a replica |
| Routing | applications must decide which queries go where |
| Failover | replicas can be promoted during outages |
Getting outside help
When to hand it over: Bring in help when database load limits growth.
Where this comes from
- Laravel Documentation — Database: Read and write connections
- Microsoft Learn — Data partitioning and replication
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
