Build fluency in the vocabulary of reliably publishing an event alongside a database update.
0 / 5 completed
1 / 5
At standup, a dev mentions writing a database update and the event describing that update to the same local transaction, then a separate process reliably publishing that event afterward. What is this pattern called?
The transactional outbox pattern writes both a database update and the event describing that update within the same local database transaction, storing the event in an outbox table, then has a separate process reliably read from that table and publish the event afterward. Publishing an event directly to a message broker in a step entirely separate from the database transaction risks the two falling out of sync if one succeeds and the other fails. Writing both within the same transaction guarantees the database change and its corresponding event are recorded together atomically.
2 / 5
During a design review, the team wants a separate background process to poll the outbox table for unpublished events and reliably publish each one to the message broker. Which capability supports this?
An outbox relay, or poller, process runs separately from the original request, polling the outbox table for unpublished events and reliably publishing each one to the message broker, retrying as needed until it succeeds. Publishing synchronously within the same request that wrote the database update reintroduces the exact coupling and failure risk the outbox pattern is meant to avoid, since the broker publish could fail even though the database write succeeded. This decoupled relay process is what actually delivers the pattern's reliability guarantee.
3 / 5
In a code review, a dev notices the relay process marks an event as published only after confirming the broker accepted it, and retries an event that's still marked unpublished. What does this represent?
At-least-once delivery is guaranteed by only marking an event as published after confirming the broker actually accepted it, and retrying any event still marked unpublished, ensuring an event never gets silently dropped due to a transient publish failure. Marking every event as published immediately regardless of confirmation risks losing an event that failed to actually reach the broker. This confirm-then-mark discipline is what gives the outbox pattern its reliability, at the cost of a consumer needing to handle the possibility of an occasional duplicate delivery.
4 / 5
An incident report shows the outbox table grew unbounded because published events were never cleaned up, eventually degrading the relay process's polling performance. What practice would prevent this?
Periodically archiving or deleting already-published events from the outbox table keeps the table's size manageable, preventing it from degrading the relay process's polling performance as the volume of processed events grows over time. Retaining every published event indefinitely with no cleanup lets the table grow without bound. This routine cleanup is a straightforward but important operational detail often overlooked when first implementing the outbox pattern.
5 / 5
During a PR review, a teammate asks why the team writes an event to an outbox table within the same transaction as the database update instead of publishing the event directly to the message broker right after the update. What is the reasoning?
Publishing an event directly to the broker immediately after a separate database update creates a window where the update succeeds but the broker publish fails, or vice versa, leaving the two out of sync. Writing both within the same local transaction guarantees they're recorded together atomically, with a separate reliable relay process handling the actual publish afterward. The tradeoff is the added infrastructure of maintaining the outbox table and a dedicated relay process rather than a simpler, if less reliable, direct publish.