Database Replication

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 DELETE to 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.

Synchronous vs. Asynchronous Replication

The fundamental tradeoff in database replication is between synchronous replication, where a write isn’t considered committed until it’s confirmed on both the primary and replica (guaranteeing no data loss on failover, at the cost of higher write latency since every write waits on network round trips to the replica), and asynchronous replication, where the primary commits a write immediately and streams it to replicas afterward (lower write latency, but some risk of data loss if the primary fails before a recent write has replicated). This tradeoff is why Multi-AZ deployments (prioritizing availability and data durability) use synchronous replication for their standby, while read replicas (prioritizing read scalability without adding write latency) use asynchronous replication — the two patterns solve genuinely different problems and make correspondingly different tradeoffs.