What Causes Replication Lag and How Do You Reduce It?
Learn the main causes of database replication lag and practical ways to reduce it, from parallel apply to hardware scaling.
Expected Interview Answer
Replication lag is the delay between a write committing on the primary and that same write becoming visible on a replica, and it is typically caused by network latency, replica hardware limits, single-threaded apply, or long-running transactions on the primary.
A replica applies changes in roughly the order it received them, so if the primary produces writes faster than the replica can apply them — because the replica has slower disks, fewer CPU cores, or applies changes single-threaded — a backlog builds up and lag grows. Network delay between primary and replica adds a floor to the lag that cannot be eliminated, and large or long-running transactions on the primary can block the replica from applying anything else until that transaction finishes replaying. Reducing lag usually means scaling replica hardware, enabling parallel/multi-threaded replication apply, keeping transactions small, and monitoring lag so read traffic can be routed away from a lagging replica.
- Parallel apply reduces single-threaded bottlenecks
- Monitoring lag prevents serving stale reads unknowingly
- Smaller transactions replay faster on replicas
- Better replica hardware narrows the apply gap
AI Mentor Explanation
A single assistant scorer copying every entry from the master scorebook by hand will always fall behind during a flurry of wickets, because writing takes longer than the events happen. If the assistant is also physically far from the ground and has to wait for a courier to deliver each page, that travel time adds unavoidable delay on top of the copying speed. Replication lag has these same two sources: how fast the replica can apply changes, and how far/slow the network path is to receive them.
Step-by-Step Explanation
Step 1
Identify the bottleneck
Determine whether lag comes from network latency, replica hardware, or single-threaded apply.
Step 2
Check for long transactions
Look for large or long-running transactions on the primary that block sequential replay.
Step 3
Scale replica resources
Add CPU, faster disks, or enable multi-threaded/parallel replication apply on the replica.
Step 4
Monitor lag continuously
Track seconds-behind-master or an equivalent metric so lagging replicas can be excluded from read routing.
What Interviewer Expects
- At least two distinct root causes (network + apply speed)
- Mention of long-running transactions as a specific cause
- A concrete mitigation, e.g. parallel apply or hardware scaling
- Awareness of why lag matters for read consistency
Common Mistakes
- Naming only network latency and ignoring apply-speed limits
- Assuming replication lag is always negligible
- Not mentioning monitoring/exclusion of lagging replicas
- Confusing replication lag with replication failure
Best Answer (HR Friendly)
“Replication lag happens when a replica cannot keep up with the primary, usually because of network delay, weaker replica hardware, or the replica applying changes one at a time. You reduce it by giving replicas more resources, enabling parallel apply, keeping transactions small, and monitoring lag so you never accidentally read stale data from a lagging replica.”
Code Example
-- MySQL: check seconds behind the master
SHOW SLAVE STATUS\G
-- look at the "Seconds_Behind_Master" field
-- PostgreSQL: check replay lag on the primary
SELECT client_addr,
state,
(pg_current_wal_lsn() - replay_lsn) AS lag_bytes
FROM pg_stat_replication;Follow-up Questions
- How would you detect that an application is reading stale data from a lagging replica?
- What is parallel replication apply and how does it help?
- How do long-running transactions on the primary affect replica lag?
- How would you design a system to tolerate eventual consistency from lag?
MCQ Practice
1. Which of these is a common cause of replication lag?
If a replica applies changes on a single thread, it can fall behind a primary generating writes faster than that thread can replay them.
2. What is a practical way to reduce replication lag caused by apply throughput?
Parallel apply lets a replica process multiple independent changes concurrently instead of one at a time, reducing backlog.
3. Why should you monitor replication lag in production?
Monitoring lag lets you exclude or warn about replicas that are too far behind to safely serve consistent reads.
Flash Cards
What is replication lag? — The delay between a write committing on the primary and appearing on a replica.
Two common causes of lag? — Network latency and limited replica apply throughput (often single-threaded).
How does a long transaction affect lag? — It can block sequential replay on the replica until it fully replays.
One way to reduce lag? — Enable parallel/multi-threaded replication apply on the replica.