What is Database Replication?

Database Replication copies data from one database (primary) to one or more databases (replicas). Two main types: Read Replicas (handle read traffic, reduce load on primary) and Failover Replicas (backup in case primary fails). Most common setup: 1 primary (handles writes), 2-3 read replicas (handle reads). Reads are 80-90% of traffic, so replicas dramatically improve performance. Much simpler than sharding.

When Should You Use This?

Use read replicas when your database CPU is high and most queries are reads (common), when you want geographic distribution (replica in EU for EU users), or for backups. Use failover replicas for high availability (if primary fails, promote replica). Add read replicas before considering sharding—they solve 90% of scaling problems with minimal complexity.

Common Mistakes to Avoid

• •Writing to replica—replicas are read-only, writes must go to primary
• •Stale reads—replicas lag behind primary (usually <1 second), critical reads must use primary
• •No monitoring—replica falls behind, app reads stale data
• •Wrong query routing—reads going to primary defeats the purpose
• •Not planning failover—replica can become primary, but need process to promote it

Real-World Examples

• •Most SaaS apps—1 primary + 2-3 read replicas, 90% reads go to replicas
• •Global apps—Replicas in each region for low latency
• •GitHub—Read replicas handle git clone requests
• •E-commerce—Product catalog reads from replicas, checkout writes to primary