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 copy of your database that handles read queries, reducing load on the primary database. Writes still go to the primary and replicate out.
In short
A read replica is a copy of a database that serves only read queries (SELECT statements), while all writes go to the primary database and stream out to the replicas. It lets you scale read traffic by spreading queries across many machines instead of overloading one server.
In short
A read replica is a copy of a database that serves only read queries (SELECT statements), while all writes go to the primary database and stream out to the replicas. It lets you scale read traffic by spreading queries across many machines instead of overloading one server.
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 Read Replica across a run of lessons, not one page. These 4 alone are about 94 minutes of step-by-step reading, every one with a quiz.
Scaling reads by replicating data to follower databases, primary-replica architecture and replication lag.
Pre-compiled SQL templates that combine security with performance, parse once, execute many times.
Writes from a single client are applied in order, preventing write reordering across replicas.
Your database already cached the disk, so what a query cache saves is CPU, and that varies by 430 times between queries.
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 Read Replicaspay once,
yours for life
Most applications read data far more often than they write it. A typical web app might do 90 reads for every 1 write: loading product pages, showing feeds, rendering profiles. A single database server can only handle so many queries per second before CPU, memory, or disk I/O become the bottleneck.
A read replica solves this by keeping a continuously updated copy of the primary database on a separate server. The primary handles every INSERT, UPDATE, and DELETE. Those changes are then shipped to one or more replicas. Your application sends write queries to the primary and routes read queries to the replicas.
The result is horizontal scaling for reads. If one server handles 5,000 reads per second, adding four replicas gets you roughly 20,000 reads per second without touching the primary. The primary stays free to do the work only it can do: accepting writes.
When you write to the primary, the change is recorded in a log before anything else happens. PostgreSQL calls this the Write-Ahead Log (WAL), MySQL calls it the binary log (binlog). The primary streams this log to each replica, which replays the same operations to stay in sync.
Most setups use asynchronous replication: the primary confirms a write to the application immediately, then sends it to the replicas a moment later. This keeps writes fast, but it creates replication lag. A replica might be 50 milliseconds behind, or several seconds behind under heavy load. During that window a read from the replica returns stale data.
This causes the classic read-your-own-writes problem. A user updates their profile (write goes to primary), the page reloads (read goes to a replica that has not caught up), and they see their old data. The fix is to route reads that must be fresh, like reading right after a write, straight to the primary, and send everything else to replicas.
Synchronous replication exists too: the primary waits for at least one replica to confirm before acking the write. This eliminates data loss on failover but slows down every write, so most systems reserve it for one critical standby and keep the rest async.
Reach for read replicas when your read load is the problem, not your write load. Reporting dashboards, analytics queries, search indexes, and heavy read APIs are good candidates because they tolerate slightly stale data and can be pointed at replicas without affecting the primary.
Read replicas do not help if writes are your bottleneck. Every replica still has to replay every write, so they all carry the same write load as the primary. To scale writes you need sharding or a different database design, not more replicas.
The main costs are stale reads from replication lag, extra money for more servers, and added complexity in your application or proxy layer to route queries correctly. A read replica can also be promoted to become the new primary if the original primary fails, which makes replicas a building block for high availability, not just scaling.
Amazon RDS and Aurora
Supports up to 15 read replicas per Aurora cluster, all reading from shared storage so lag is usually under 100 milliseconds.
PostgreSQL
Ships built-in streaming replication over the WAL, with hot standbys that serve read queries while staying ready for failover.
MySQL
Uses binlog-based replication; companies like GitHub run large replica fleets and route reads through a proxy that respects lag.
MongoDB
Replica sets keep secondary nodes in sync with the primary, and a read preference setting lets the driver send reads to secondaries.
A backup is a frozen snapshot taken at a point in time, stored for recovery. A read replica is a live, continuously updated copy you can actually query right now. Backups protect against data loss; read replicas serve traffic.
No, replicas are read-only by design. Writing to them would break synchronization with the primary. If a replica is promoted to primary during a failover, it then accepts writes, but a normal replica only serves reads.
Replication lag is how far behind a replica is compared to the primary, usually milliseconds but sometimes seconds under load. It matters because a read from a lagging replica can return stale data, so freshness-critical reads should go to the primary.
No. Every replica replays every write, so they all carry the same write load as the primary. Read replicas only scale reads. For write scaling you need sharding or partitioning instead.
Either your application code splits reads and writes explicitly, or a proxy like ProxySQL or PgBouncer routes them automatically. A common rule is to send writes and read-after-write queries to the primary and everything else to replicas.
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
An organized collection of data that can be easily accessed, managed, and updated. The backbone of almost every application.
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 "Read Replicas" 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 Read Replicas lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Read 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.
