Senior · Architecture and systems
Idempotency, outbox and retries
How do you keep an accepted order and its published event consistent?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
A database commit and a remote broker publish are separate failure boundaries. Publishing before commit may announce rolled-back data; publishing after commit may be skipped if the process crashes.
Write an outbox record in the same transaction as the domain state. A relay publishes pending records and tracks progress. Crashing after publish but before marking sent can still duplicate delivery.
Consumers need a durable idempotency decision in the same atomic boundary as their side effect, using event/operation IDs. “Exactly once” must name the scope and failure model; an in-memory dedup set is not durable correctness.
Common trap
An outbox prevents a lost publication gap, but does not magically prevent every duplicate.
Try it
The relay publishes and crashes before updating its outbox row. What should the consumer do on redelivery?
Worked solution
Check or claim the event ID using a durable uniqueness rule in the consumer's transaction with its state change. A duplicate can acknowledge the already applied result. External side effects need their own idempotency key or reconciliation.
Change the constraint
How do you retain deduplication records long enough without unbounded storage growth?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.