Read Replicas

Additional copies of your database that handle read traffic only — writes still go to master.

Why Read Replicas Exist

Typical web application: 80-90% reads, 10-20% writes. Without read replicas all reads hammer the master. With read replicas, reads spread across replicas and master focuses on writes.

Replication Lag — The Main Problem

User writes a post → goes to Master. User immediately reads their feed → goes to Replica → Replica hasn't synced yet → User doesn't see their own post.

Solutions

• Read your own writes from Master — after any write, route that user's next read to master for a short window
• Sticky sessions — same user always reads from same replica
• Application-level tolerance — social feeds: lag is fine; bank balance: must read from master

Read From Master vs Replica

Read from MASTER	Read from REPLICA
Immediately after a write (your own writes)	Social media feeds
Financial data (balance, transactions)	Product listings
Inventory counts (don't oversell)	Analytics dashboards
Anything where stale = dangerous	Reports and aggregations

Read Replicas vs Caching

	Read Replicas	Caching (Redis)
Data coverage	Full database copy	Only explicitly cached data
Query support	Any SQL query	Simple key lookups
Freshness	Relatively fresh	Can be stale longer
Speed	Fast	Much faster (in-memory)
Best for	Complex queries	Frequent identical queries

Real systems use BOTH: Cache hit → Redis. Cache miss → Read replica. Write → Master.

Cloud Read Replicas

Platform	Features
AWS RDS	Up to 5 read replicas per instance, one click to create
AWS Aurora	Up to 15 read replicas, shared storage (no replication lag!)
Google Cloud SQL	Read replicas across regions
Azure SQL	Up to 4 readable secondaries (active geo-replication)