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 LearningIntermediate · Data Replication & Distribution
A replication topology where one node (primary) handles writes and replicates changes to one or more read-only replicas. The foundation of most database scaling strategies.
In short
Primary-replica is a database replication setup where one node, the primary, accepts all writes and streams its changes to one or more read-only replicas that serve read queries. It lets you scale reads horizontally and keep a hot standby for failover, at the cost of replicas lagging slightly behind the primary.
In short
Primary-replica is a database replication setup where one node, the primary, accepts all writes and streams its changes to one or more read-only replicas that serve read queries. It lets you scale reads horizontally and keep a hot standby for failover, at the cost of replicas lagging slightly behind the primary.
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 Primary-Replica across a run of lessons, not one page. These 4 alone are about 98 minutes of step-by-step reading, every one with a quiz.
The most common replication topology, one writer, many readers, and the trade-offs that come with it.
Scaling reads by replicating data to follower databases, primary-replica architecture and replication lag.
Set up an active-passive PostgreSQL database: a primary and a streaming standby, slots, synchronous_commit, hot standby and fencing, run in a real lab.
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.
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 Master-Slave Replicationpay once,
yours for life
A primary-replica topology has exactly one writable node and one or more copies of it. The primary (older docs call it master) is the only node that accepts inserts, updates, and deletes. Every replica (older docs call it slave) holds a continuously updated copy of the primary's data and answers read queries only.
The point is to split traffic by intent. Writes funnel to one node so there is a single source of truth and no conflict resolution to worry about. Reads spread across many replicas, so a read-heavy app like a news site or product catalog can serve far more traffic than a single machine could.
This is the default scaling story for relational databases. Postgres, MySQL, and managed services like Amazon RDS and Aurora all ship with primary-replica replication built in. It is simple to reason about because there is never a question of which node owns the truth: the primary always does.
The primary records every change to a write-ahead log (Postgres calls it the WAL, MySQL calls it the binary log). This log is an ordered stream of every modification in the exact order it happened. Replicas connect to the primary, pull that log, and replay it against their own copy to stay in sync.
Replication can be asynchronous or synchronous. With async replication, the primary commits a transaction and tells the client it succeeded without waiting for any replica to confirm. This is fast but means a replica can be a few milliseconds to several seconds behind. That gap is called replication lag. With synchronous replication, the primary waits for at least one replica to confirm the write before acknowledging the client, which guarantees no data loss on failover but adds latency to every write.
When the primary dies, a process called failover promotes one replica to become the new primary. Tools like Patroni for Postgres or Orchestrator for MySQL detect the failure, pick the most up-to-date replica, and repoint application traffic. Until promotion finishes, writes are blocked, so failover speed directly affects your downtime.
Reach for primary-replica when your workload is read-heavy and your write volume fits on one machine. A typical web app reads far more than it writes, sometimes 10 to 1 or 100 to 1, so adding read replicas buys a lot of capacity cheaply. It also gives you a hot standby for high availability and a place to run heavy analytics queries without slowing down production writes.
The big trade-off is replication lag combined with eventual consistency on the read path. If a user updates their profile and the very next page load hits a stale replica, they see the old data. The common fix is read-your-own-writes routing: send a user's reads to the primary for a short window after they write, or route critical reads to the primary always.
The other hard limit is write scaling. Because only one node accepts writes, primary-replica does nothing for a write-bottlenecked system. Once writes outgrow a single primary you need sharding (splitting data across multiple primaries) or a multi-primary or distributed system like CockroachDB or Cassandra. Adding more replicas never helps write throughput.
Picture an e-commerce store running on Postgres. The primary handles checkout, inventory decrements, and order writes. Three read replicas sit behind a connection proxy and serve product page views, search, and the recommendation feed. On a normal day the primary handles maybe 2,000 writes per second while the replicas collectively serve 50,000 reads per second.
During a flash sale, read traffic spikes. The team spins up two more replicas in minutes and the proxy starts routing reads to them. The primary is untouched, so checkout stays fast. When a replica falls 5 seconds behind because of a replication hiccup, the proxy temporarily stops sending it traffic until it catches up.
One night the primary's disk fails. Patroni detects it within a few seconds, promotes the most caught-up replica to primary, and updates the DNS or proxy config. Writes resume after roughly 10 to 30 seconds of downtime, and because they ran synchronous replication to one replica, no committed order was lost.
Amazon RDS and Aurora
Managed Postgres and MySQL where you provision a writer instance plus up to 15 read replicas, with automated failover.
PostgreSQL
Ships streaming replication out of the box using the WAL; primary streams changes to standbys that can serve reads.
MySQL
Binary-log replication is the classic primary-replica model that powers read scaling at companies like Facebook and Booking.com.
Redis
Replica nodes copy the primary and serve reads, with Redis Sentinel handling automatic failover when the primary goes down.
They are the same architecture. Master-slave is the older term, and the industry has largely renamed it to primary-replica (or primary-secondary) to drop the offensive language. The behavior is identical: one writable node, one or more read-only copies.
No. In a standard primary-replica setup, replicas are read-only. All writes must go to the primary, which then propagates them. If you need multiple writable nodes, you are looking at multi-primary or distributed databases, which add conflict resolution complexity.
Replication lag is the delay between a write committing on the primary and that change appearing on a replica. With async replication it can be milliseconds to seconds. It matters because a read hitting a lagging replica returns stale data, so users can briefly see old values after an update.
A monitoring tool detects the primary is down, selects the most up-to-date replica, and promotes it to primary, then repoints application traffic to it. Tools like Patroni, Orchestrator, or Redis Sentinel automate this. Writes are blocked until promotion completes, so failover time equals your write downtime.
No. Every write still goes through the single primary, so replicas do nothing for write throughput. They only scale reads. To scale writes you need sharding or a distributed database that supports multiple write nodes.
Read Replica
A copy of your database that handles read queries, reducing load on the primary database. Writes still go to the primary and replicate out.
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
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.
Database Partitioning
Dividing a large table into smaller, more manageable pieces while keeping them in the same database. Sharding is partitioning across servers.
Write-Ahead Log
A technique where changes are written to a log before being applied to the database. Ensures durability and crash recovery.
Consistent Hashing
A hashing technique where adding or removing servers only moves a small fraction of keys. Used by Amazon DynamoDB and Cassandra for data distribution.
This page explains the idea. The "Master-Slave 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 Master-Slave Replication lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Primary-Replica 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.
