Hard Database Engineering interview problem
Outbox Publishes Phantom and Duplicate Events
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
An order workflow sometimes emits an event for an order that never committed and sometimes commits an order with no event. After scaling publishers horizontally, a single outbox row can also be delivered more than once.
This is a hard production-debugging exercise because the write-side atomicity problem and the multi-worker claiming problem are related but require separate database guarantees. 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
Accepted orders and their order.placed records belong to one database transaction. Independent publisher workers claim bounded batches, deliver them, and record completion without serialising the whole service.
The starter writes business state and outbox state across different commit boundaries, then lets workers select the same unpublished rows without a safe claim protocol. Failures create phantom or missing events; concurrency creates duplicates.
What you’ll practice
- Writing business rows and outbox events atomically
- Rolling back rejected orders without leaving publishable work
- Claiming batches safely with concurrent publishers
- Preserving publisher throughput without a global lock
- Distinguishing delivery identity from polling retries
How to approach it
First prove the one-to-one relationship between committed orders and outbox rows at every failure boundary. Then run multiple publishers against one eligible row and inspect which database operation grants ownership.
Keep batch selection, claim state, and completion state coherent. The database should prevent two workers from owning the same work while allowing them to make progress on different rows.
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 Outbox Publishes Phantom and Duplicate Events?
Begin with order and outbox commit boundaries, rejected writes, publisher claims, concurrent delivery records, and batch limits. 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 write-side atomicity problem and the multi-worker claiming problem are related but require separate database guarantees. 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.