Learn the vocabulary of the delay before a read replica reflects a primary's latest committed writes.
0 / 5 completed
1 / 5
At standup, a dev mentions the delay between when a write commits on a database's primary node and when that same write becomes visible on a read replica, caused by the time it takes to ship and apply the change. What is this delay called?
Replication lag is exactly this: it is the delay between when a write commits on a database's primary node and when that same write becomes visible on a read replica, caused by the time it takes to ship the change over the network and apply it on the replica. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This ship-and-apply-delay is exactly why a read immediately after a write can return stale data if it happens to land on a replica that hasn't caught up yet.
2 / 5
During a design review, the team monitors replication lag on every read replica and routes a user's read back to the primary immediately after that same user's write, specifically because a replica that hasn't caught up yet could return stale data for that user's own recent change. Which capability does this provide?
Monitoring replication lag and routing here provide avoiding stale reads immediately after a user's own write, since routing that read to the primary sidesteps any replica that hasn't yet applied the user's own recent change. Always reading from any replica regardless of its lag risks showing a user a page that doesn't yet reflect the change they just made. This route-around-lagging-replicas behavior is exactly why monitoring replication lag is standard practice wherever read-after-write consistency matters to users.
3 / 5
In a code review, a dev notices a feature always reads from a randomly selected replica immediately after a user submits a write, with no monitoring of replication lag and no routing back to the primary for that user's own subsequent read. What does this represent?
This is a missed opportunity to account for replication lag, since routing a user's read-after-write back to the primary would avoid a lagging replica showing that user stale data right after their own change. A cache eviction policy is an unrelated concept about discarded cache entries. This random-replica-read-after-write pattern is exactly the kind of confusing staleness a reviewer flags once users expect to see their own change reflected immediately.
4 / 5
An incident report shows users repeatedly reported that a profile update appeared to silently revert moments after saving, because the feature always read from a randomly selected replica right after the write with no accounting for replication lag. What practice would prevent this?
Routing a user's read immediately after their own write to the primary means replication lag on a replica can never make that recent change appear to have reverted. Continuing to read from a randomly selected replica immediately after every write regardless of how often users see their own recent change appear to revert is exactly what caused the confusion described in this incident. This read-after-write-to-primary routing is the standard fix once replication lag is confirmed to cause visible staleness right after a user's own write.
5 / 5
During a PR review, a teammate asks why the team routes a user's read-after-write to the primary instead of simply waiting a fixed delay before reading from a replica, given that a fixed delay is simpler to implement. What is the reasoning?
Routing to the primary guarantees the freshest possible read regardless of how long replication actually takes at that moment, while a fixed delay is simpler but must either be long enough to cover the worst-case lag, adding unnecessary latency most of the time, or risk still being too short during an unusually slow replication period. This is exactly why routing read-after-write to the primary is preferred whenever replication lag can vary unpredictably.
What does the "Database Replication Lag Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to database replication lag vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 9 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.