How Database Replication Works
IntermediateReplication keeps copies of your database on multiple servers. The most common setup is primary-replica: one primary handles writes and streams its changes to read replicas that serve read queries. This scales reads, provides high availability (a replica can be promoted if the primary fails), and enables geographic distribution. The key trade-off is replication lag — asynchronous replicas can briefly serve slightly stale data.
Think of replication as a lead scribe and copyists
A lead scribe (the primary) writes the official record. Several copyists (replicas) continuously transcribe from the lead so visitors can read from any of them, spreading the reading load. If copies are made instantly (synchronous), everyone always sees the latest word — but the lead must wait for copyists to confirm. If copies lag a little (asynchronous), the lead writes freely, but a reader might briefly see yesterday sentence.
Step by Step
Key Concepts
Primary-Replica
One writable primary streams changes to read-only replicas. The standard pattern for scaling reads and providing high availability (formerly called master-slave).
Replication Lag
The delay before a replica reflects the primary latest writes. With async replication a read replica may briefly return stale data — an important consideration for read-after-write consistency.
Synchronous vs Asynchronous
Synchronous waits for replica acknowledgement before committing (durable, slower). Asynchronous commits first and replicates after (fast, small risk of losing recent writes on failure).
Failover
Promoting a replica to primary when the current primary fails. Automated failover minimises downtime; the promoted replica must be as up-to-date as possible to avoid data loss.
Key Facts
- Replication scales reads, not writes — all writes still funnel through the single primary (to scale writes you need sharding).
- After a user writes data, immediately reading from an async replica can show stale data; route read-after-write to the primary or use replica lag checks.
- Multi-primary (multiple writable nodes) removes the single write bottleneck but introduces write-conflict resolution, which is complex — most systems avoid it.
Real-World Applications
Scaling a read-heavy app
A product or content site with far more reads than writes adds read replicas and routes all reads to them, keeping the primary free for writes and multiplying read capacity cheaply.
High availability for critical data
A synchronous standby replica in another availability zone means that if the primary fails, failover promotes the standby with no committed data lost — meeting strict durability requirements.
Frequently Asked Questions
What is the difference between synchronous and asynchronous replication?
Synchronous replication waits for at least one replica to confirm receipt before the write commits — guaranteeing no data loss but adding latency. Asynchronous replication commits on the primary immediately and copies to replicas afterward — faster, but a primary crash can lose the most recent, not-yet-replicated writes.
What is replication lag?
It is the delay between a write committing on the primary and appearing on a replica. With asynchronous replication, a read from a lagging replica can return slightly stale data. This matters for read-after-write scenarios, where you may need to read from the primary instead.
Does replication scale writes?
No. In primary-replica replication all writes go through the single primary, so replication scales reads (by adding replicas) but not writes. To scale write throughput beyond one machine you need sharding, which partitions writes across multiple primaries.
What happens during a failover?
When the primary becomes unavailable, a replica is promoted to be the new primary and application traffic is redirected to it. Automated tooling detects the failure and picks the most up-to-date replica to minimise both downtime and potential data loss.