System designHard~20 minData Integrity & Transactions / 9 of 14

Interview question

How would you make sure a database update and a message publish do not get out of sync?

Outbox pattern for database and message consistency

Uses a transactional outbox to make a local state change durably publishable while accepting at-least-once delivery and operating the backlog safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I write the business change and an outbox row in the same database transaction. After commit, a dispatcher reads pending rows and publishes them. If the process crashes before publishing, the row remains for retry; if the database transaction rolls back, there is no message to publish. This closes the gap between saving data and remembering that an integration event still needs to be sent.

Full answer below

Practice focus

Understanding of the outbox pattern for database and message consistency, EF Core/SQL behavior, API boundaries, production risks, and practical debugging or design judgment.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A local database transaction cannot atomically commit an independent broker publish. The outbox makes the intent to publish part of the same durable state as the business change, then crosses the broker boundary asynchronously.
I write the business change and an outbox row in the same database transaction. After commit, a dispatcher reads pending rows and publishes them. If the process crashes before publishing, the row remains for retry; if the database transaction rolls back, there is no message to publish. This closes the gap between saving data and remembering that an integration event still needs to be sent.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The dispatcher claims work in bounded batches so multiple workers do not constantly publish the same rows, but it still assumes at-least-once delivery. Publishing may succeed and marking the row sent may fail, so consumers deduplicate by message or business-operation id and apply their own state change idempotently. Ordering is defined per aggregate or partition where the business requires it, rather than promising one global order. Poison messages move to a visible failure state instead of blocking the entire queue.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production the outbox is an operated delivery pipeline, not just a table. I monitor oldest pending age, backlog growth, publish latency, attempts, poison count, and consumer duplicate rate. Payloads carry stable event ids, correlation and causation ids, occurred time, schema version, and only the data consumers are allowed to receive. Cleanup is retention-based and cannot remove rows still needed for replay or investigation. Dispatch can use polling with safe leases, database notifications, or change-data capture depending on throughput and platform support. Admin replay preserves identifiers and records the reason so it does not create a new logical event accidentally. I choose the pattern for business-critical integration; low-value notifications may accept a simpler failure model.

Coding practice

Practice the problem like a real interview: restate, reason, implement, and test.

ExampleCandidatePractical exampleWalk through sample input and output.Open details

Details

A checkout API can save Order, OrderLine, and an outbox message in one transaction. If the API crashes after commit, the worker still publishes the order-created event later.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Publishing before commit and emitting an event for data that later rolls back.
Assuming marking a row sent makes broker delivery exactly once.
Having no consumer idempotency, poison handling, or backlog alert.
Deleting outbox history before the replay and support window ends.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot explain how the outbox pattern for database and message consistency affects API behavior.
Gives only a definition with no practical example.
Ignores production failure modes.
Does not know how to verify the behavior.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

What failure does the outbox pattern solve?
Why do consumers still need idempotency?
How do you monitor outbox backlog?
When would the outbox pattern be overkill?

Continue the section

Next in Data Integrity & Transactions: Transaction Outbox

Step 10 of 14

Design an EF Core transaction boundary with an outbox

Opening drill

How would you make sure a database update and a message publish do not get out of sync?

Outbox pattern for database and message consistency

Uses a transactional outbox to make a local state change durably publishable while accepting at-least-once delivery and operating the backlog safely.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

How would you make sure a database update and a message publish do not get out of sync?

Practice focus

Answer path

Why this question matters

Coding practice

Review signals

Follow-up prompts

Continue the section

How would you make sure a database update and a message publish do not get out of sync?

Practice focus

Answer path

Why this question matters

Coding practice

Review signals

Follow-up prompts

Continue the section