We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Database Fundamentals
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
In short
Replication keeps copies of the same data on multiple servers. The common setup is leader-follower: all writes go to one primary, which streams its changes to read replicas that serve reads and stand ready to take over if the primary fails. It buys read scale and fault tolerance, and its central trade-off is replication lag, the short window where a replica has not yet caught up with the latest write.
In short
Replication keeps copies of the same data on multiple servers. The common setup is leader-follower: all writes go to one primary, which streams its changes to read replicas that serve reads and stand ready to take over if the primary fails. It buys read scale and fault tolerance, and its central trade-off is replication lag, the short window where a replica has not yet caught up with the latest write.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Replication across a run of lessons, not one page. These 4 alone are about 70 minutes of step-by-step reading, every one with a quiz.
Keeping copies of your data on multiple servers, the foundation of every highly available system.
The most common replication topology, one writer, many readers, and the trade-offs that come with it.
The default replication mode, fast writes at the cost of potential data loss.
Synchronous replication waits for a replica to confirm each write, so no data is lost on failover. Compares sync, semi-sync and async replication.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Database Replicationpay once,
yours for life
Replication means keeping more than one copy of your data on different servers. Teams reach for it for two reasons. The first is fault tolerance: if the only copy of your data lives on one machine and that machine dies, you have an outage and possibly data loss. With replicas, another copy can take over. The second is read scaling: most systems read far more than they write, and a single database can become a read bottleneck. Spreading reads across several copies multiplies your read capacity.
It is worth being precise about the difference from sharding, because they are often confused. Replication copies the same data to many servers. Sharding splits different data across servers. Replication scales reads and survives failures; sharding scales writes and storage. Large systems usually do both: shard the data into pieces, then replicate each piece.
The most common arrangement is leader-follower, also called primary-replica or master-slave. One server is the primary and is the only one that accepts writes. It records every change to its data and streams that change log to the followers, the replicas, which apply the same changes in the same order. Reads can be served by the primary or, more usefully, spread across the replicas to take load off the primary.
If the primary fails, one of the replicas is promoted to be the new primary, a process called failover. This is why even a system that does not need extra read capacity often keeps at least one replica: it is the difference between a quick failover and a long outage with a restore from backup.
Leader, follower replication
All writes go to the primary, which streams its changes to the replicas. Reads can be spread across the replicas.
The key choice is when the primary considers a write done. With synchronous replication, the primary waits for at least one replica to confirm it has the change before telling the client the write succeeded. This guarantees the replica is current, but the write is only as fast as the slowest replica it waits for, and if that replica is down the write stalls.
With asynchronous replication, the primary acknowledges the write immediately and streams it to replicas in the background. This is fast and the primary never waits, but it opens a gap: for a brief moment the replicas are behind the primary. That gap is replication lag, often a few milliseconds but sometimes seconds under load.
Replication lag causes a specific, surprising bug. A user writes something, the write goes to the primary, then their next read is served by a replica that has not caught up yet, so their own change appears to have vanished. This is the read-your-own-writes problem. Common fixes are to route a user's reads to the primary for a short window after they write, or to use replicas that track how far behind they are and skip the ones that are too stale.
In a real system
Writes go to the primary, reads spread across the replicas, and the primary streams its change log to keep the replicas up to date.
Leader-follower has one writable node, which is simple but means all writes funnel through one machine and one region. Two other models trade simplicity for write availability. Multi-leader replication allows writes on more than one primary, which helps across regions, but creates write conflicts when two leaders change the same row, so it needs conflict-resolution rules.
Leaderless replication, used by systems like Cassandra and the original Dynamo, drops the special primary entirely: a client writes to several nodes at once and reads from several at once, using quorums to decide what the current value is. It is highly available and partition tolerant, at the cost of weaker consistency guarantees that the application has to reason about.
Replication keeps standby copies up to date; failover is what uses them. The database failover page covers how a standby is promoted, how much data asynchronous replication can lose, and how fencing prevents split brain.
PostgreSQL
Ships streaming replication: a primary streams its write-ahead log to read replicas, with a choice of synchronous or asynchronous mode.
MySQL
Binlog-based replication is the classic primary-replica setup, widely used to scale reads and run failover.
MongoDB
Replica sets keep several copies with automatic election of a new primary on failure, the standard durable MongoDB deployment.
Apache Cassandra
Leaderless replication with tunable quorums, so any node can take a write and consistency is dialled per query.
Replication keeps copies of the same data on multiple servers. It provides fault tolerance, since another copy can take over if one server fails, and read scaling, since reads can be spread across the copies. The common setup is leader-follower, where one primary takes writes and streams changes to read replicas.
Replication copies the same data to multiple servers to scale reads and survive failures. Sharding splits different data across servers so each holds only a slice, to scale writes and storage. They solve different problems and large systems often use both: shard the data, then replicate each shard.
Synchronous replication makes the primary wait for a replica to confirm a change before acknowledging the write, so the replica is always current but writes are slower and can stall if a replica is down. Asynchronous replication acknowledges immediately and copies to replicas in the background, which is faster but lets replicas briefly fall behind.
Replication lag is the short delay between a write being applied on the primary and that change appearing on a replica, common with asynchronous replication. It is often milliseconds but can grow to seconds under load. It causes the read-your-own-writes problem, where a user's own recent change seems to disappear when their next read hits a replica that has not caught up.
Route a user's reads to the primary for a short window after they write so they always see their own change, or use replicas that report how far behind they are and skip ones that are too stale. Both ensure a user sees their own recent writes even though other reads still go to replicas.
Master-Slave Replication
The most common replication topology, one writer, many readers, and the trade-offs that come with it
Asynchronous Replication
The default replication mode, fast writes at the cost of potential data loss
Synchronous Replication
Synchronous replication waits for a replica to confirm each write, so no data is lost on failover. Compares sync, semi-sync and async replication.
Multi-Master Replication
Multi-master replication lets several nodes accept writes. See how it works, a concrete example of a write conflict, and when it is worth the cost.
Binlog Replication
MySQL's binary log, the engine behind MySQL replication and CDC
Sharding
Splitting a database into smaller pieces (shards) distributed across multiple servers. Each shard holds a subset of the data.
Leader Election
The process of choosing one node in a cluster to coordinate actions. If the leader fails, a new one is elected. Used by Kafka, ZooKeeper, and etcd.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
Write-Ahead Log
A technique where changes are written to a log before being applied to the database. Ensures durability and crash recovery.
Database
An organized collection of data that can be easily accessed, managed, and updated. The backbone of almost every application.
SQL
Structured Query Language for managing relational databases. Tables, rows, columns, and powerful joins to query related data.
This page explains the idea. The "Database Replication" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Database Replication lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Replication in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
