Hard Database Engineering interview problem
Read Replica Serves Stale Data After a Write
Written and reviewed by Sahil Srivastav
This problem is available as the same repository challenge in Python, Java, Node.js, and C++. Open the full problem and choose a language
What this interview round tests
Moving order reads to a replica reduces primary load but creates a user-visible regression: a customer places an order and immediately cannot see it. Refreshing later works because replication eventually catches up.
This is a hard production-debugging exercise because the repair must be session-aware and temporary: always using the primary is correct but defeats the architecture and fails the routing contract. It tests whether you can move from operational evidence to a narrow invariant, then make a repair that survives concurrency, retries, failures, or workload growth instead of merely passing one happy-path example.
The scenario
The primary assigns each committed order a monotonic sequence number, and the replica records the highest sequence it has applied. The router must preserve a session’s read-after-write guarantee without permanently pinning all traffic to the primary.
The current router treats every replica as eligible regardless of the session’s last write. A recent writer can therefore read below its required consistency point even though enough progress information exists to make the decision safely.
What you’ll practice
- Defining a per-session consistency watermark
- Comparing replica progress with a required write sequence
- Falling back to primary only while lag matters
- Returning to replica reads after catch-up
- Testing deterministic lag without background timing
How to approach it
Treat the write receipt as a minimum visibility requirement carried by the session. At each read, compare that watermark with replica progress before selecting a source.
Cover all three states explicitly: no dependent write, replica behind the requirement, and replica caught up. Validate both returned data and router source so an all-primary shortcut cannot masquerade as a solution.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
What should I inspect first in Read Replica Serves Stale Data After a Write?
Begin with the write receipt sequence, replica applied sequence, session state, and the router’s chosen source for each read. The supplied evidence narrows the failure mode before you touch the implementation, which is the same evidence-first habit expected during a production incident or senior backend interview.
What makes this a hard database engineering problem?
It is hard because the repair must be session-aware and temporary: always using the primary is correct but defeats the architecture and fails the routing contract. The test suite checks the underlying invariant and adverse execution paths, so a local patch or a larger resource limit will not satisfy the challenge.
Which languages can I use for this repository challenge?
The same scenario is implemented in Python, Java, Node.js, and C++. Each language directory includes its own source, evidence or database setup, tests, and verify.sh entry point while preserving the same production invariant.