What Are Read Replicas and How Do They Scale Reads?
Learn how read replicas scale database reads, how replication lag affects consistency, and how to route reads vs writes.
Expected Interview Answer
A read replica is a copy of a primary database that continuously receives updates via replication and serves read-only queries, letting an application scale read throughput horizontally by spreading queries across multiple replicas while all writes still go to the single primary.
The primary database handles all writes and streams its changes — either through logical replication (row-level changes) or physical replication (writing the same write-ahead log) — to one or more replicas, which apply those changes to stay in sync. Applications route read-heavy traffic (like rendering a dashboard or product page) to replicas, freeing the primary to focus on writes and reducing contention. Because replication is typically asynchronous, replicas lag behind the primary by some amount, so a read immediately after a write can return stale data unless the application explicitly reads from the primary for that request (read-after-write consistency) or waits for the replica to catch up. Read replicas also serve as a warm standby for failover and let heavy analytical queries run against a replica without slowing down production writes on the primary.
- Scales read throughput horizontally by adding more replicas without touching the write path
- Isolates heavy analytical or reporting queries from production write traffic
- Provides a warm standby that can be promoted to primary during a failover
- Reduces load and lock contention on the primary, improving write latency
AI Mentor Explanation
A read replica is like the official scorer keeping the master scorebook (the primary) while several assistant scorers each maintain their own copy, updated moments after every ball, so spectators asking for the current score can check any assistant’s copy instead of crowding the official scorer. The assistants never write new entries themselves — only the official scorer does that — they just replicate what has been recorded. Because there is a tiny delay before an assistant’s copy catches up, someone checking an assistant’s book right after a boundary might briefly see the old total. That read-scaling-with-a-slight-lag pattern is exactly how read replicas work in a database.
Step-by-Step Explanation
Step 1
Writes go to the primary
All insert, update, and delete operations are sent exclusively to the primary database.
Step 2
Changes stream to replicas
The primary continuously ships its write-ahead log or row-level changes to one or more replicas via replication.
Step 3
Replicas apply changes and stay read-only
Each replica applies incoming changes and serves read queries, but rejects writes.
Step 4
Application routes reads to replicas
A router, connection pool, or ORM setting directs read-heavy queries to replicas, reserving the primary for writes and read-after-write cases.
What Interviewer Expects
- Explains that writes always go to the primary while reads can be spread across replicas
- Mentions replication lag and its consequence: eventual consistency for replica reads
- Discusses read-after-write consistency and how to solve it (route to primary, or wait for replica catch-up)
- Notes replicas can also serve as failover standbys and isolate analytical workloads
Common Mistakes
- Assuming replicas can accept writes directly
- Ignoring replication lag and the stale-read risk right after a write
- Not having a strategy for read-after-write consistency on critical paths
- Treating a replica as a full disaster-recovery solution without discussing promotion/failover mechanics
Best Answer (HR Friendly)
“A read replica is a copy of the main database that stays in sync with it and only handles read queries, while all the writes still go to the one main database. This lets an application spread out heavy read traffic across several replicas so the main database is not overwhelmed, though replicas can be a moment behind since syncing is not instant.”
Code Example
const primaryPool = createPool({ host: "db-primary.internal" })
const replicaPools = [
createPool({ host: "db-replica-1.internal" }),
createPool({ host: "db-replica-2.internal" }),
]
function pickReplica() {
return replicaPools[Math.floor(Math.random() * replicaPools.length)]
}
async function createOrder(order) {
// writes always go to the primary
return primaryPool.query(
"INSERT INTO orders (user_id, total) VALUES ($1, $2) RETURNING id",
[order.userId, order.total]
)
}
async function getOrderHistory(userId, { readYourOwnWrite = false } = {}) {
// read-after-write cases route to the primary to avoid replica lag
const pool = readYourOwnWrite ? primaryPool : pickReplica()
return pool.query("SELECT * FROM orders WHERE user_id = $1", [userId])
}Follow-up Questions
- How would you handle read-after-write consistency when a user expects to see their own recent write immediately?
- What is the difference between synchronous and asynchronous replication, and how does each affect replica lag?
- How would you promote a read replica to primary during a failover?
- How do read replicas interact with sharding when a system needs both read scaling and write scaling?
MCQ Practice
1. In a primary-replica setup, where do write operations go?
Writes are always directed to the primary; replicas receive changes through replication and stay read-only.
2. Why might a read immediately after a write return stale data with asynchronous replication?
With asynchronous replication, there is a delay before a replica catches up to the primary, so a read routed to a replica right after a write can see the old value.
3. Besides scaling reads, what is another common use of a read replica?
A read replica can be promoted during failover and can absorb heavy reporting or analytics workloads without impacting the primary.
Flash Cards
What is a read replica? — A read-only copy of a primary database kept in sync via replication, used to scale read throughput.
Where do writes go in a primary-replica setup? — Always to the primary; replicas only apply replicated changes and serve reads.
Why can a replica return stale data? — Asynchronous replication lag means the replica may not yet have applied the most recent write.
What solves read-after-write consistency? — Routing that specific read to the primary, or waiting until the replica has caught up to the write.