Aliases: Read replica, Primary-replica
Database Replication
Keeping copies of a database on multiple servers for availability, read scaling, and disaster recovery — with consistency as the price of admission.
What is replication?
Replication maintains copies of your data across servers. The dominant pattern is primary-replica: one node accepts writes, replicas receive the change stream and serve reads. It buys you availability (replica promoted if the primary dies), read scaling (fan reads out to replicas), and geography (replicas near users, and a copy surviving a regional outage).
Sync vs async — the fundamental trade
Asynchronous replication (the default): the primary confirms writes immediately, replicas catch up milliseconds-to-seconds later. Fast, but a primary failure can lose the last moments of writes, and replicas serve stale reads. Synchronous: the primary waits for replica acknowledgment — no loss, but every write pays the latency and a slow replica stalls writes. Most systems mix: one sync replica for durability, async for the rest.
Replication lag — the bug factory
The classic: user updates their profile (write → primary), page reloads (read → replica), old data appears. The write isn’t lost — the replica is behind. Fixes: read-your-own-writes routing (send a user’s reads to the primary briefly after they write), sticky sessions, or monitoring lag and pulling laggy replicas from rotation. Every team hits this bug exactly once in production.
Beyond primary-replica
Multi-primary (writes anywhere) introduces conflict resolution — hard; avoid unless geography demands it. Consensus-based systems (Spanner, CockroachDB, Aurora’s storage layer) get stronger guarantees with different cost profiles. Managed databases (RDS, Cloud SQL) make replicas a checkbox — the concepts remain your problem.
What people get wrong
- Confusing replicas with backups. Replication faithfully copies your accidental
DELETEto every node in milliseconds. You still need point-in-time backups. - Reading from replicas without a staleness plan. Decide per query whether stale is acceptable.
- Untested failover. Promotion that’s never been rehearsed fails at 3 a.m.; run failover drills like the SLA depends on it — it does.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.