Primary-Replica
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.
What is Primary-Replica?
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.
What primary-replica replication is
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.
How it works under the hood
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.
When to use it and the trade-offs
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.
A concrete real-world example
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.
Where it is used in production
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.
Frequently asked questions
- What is the difference between primary-replica and master-slave?
- 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.
- Can replicas accept writes?
- 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.
- What is replication lag and why does it matter?
- 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.
- How does failover work if the primary crashes?
- 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.
- Does adding more read replicas help with write performance?
- 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.
Learn Primary-Replica hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Primary-Replica as part of a larger topic.
Master-Slave Replication
The most common replication topology, one writer, many readers, and the trade-offs that come with it
foundation · database fundamentals
Read Replicas
Scaling reads by replicating data to follower databases, primary-replica architecture and replication lag
foundation · database fundamentals
See also
Related glossary terms you might want to look up next.
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.