Transactional outbox delivery

Ask where the consumer records a duplicate

The outbox makes publication recoverable, which also makes repeated delivery possible. Review duplicate handling at the consumer's actual side-effect boundary.

In this article

Trace one event into the effect

Choose a synthetic event and identify the record or external action the consumer creates. Find the event identifier used to recognise repeated delivery.

If the consumer writes to a local database, inspect whether the processed-event marker and business effect commit together. Writing the marker first can suppress an effect that later fails. Writing it after a separate commit can leave a duplicate window.

Use the database's actual transaction and uniqueness guarantees. A read-then-insert check without concurrency protection can allow two workers to process the same event simultaneously.

Examine external side effects separately

For a downstream API call, a local transaction cannot make the remote effect atomic. Review the downstream idempotency key, retention and status lookup or reconciliation path.

Ask what happens after the external service commits but the response is lost. The consumer should not infer failure and create a fresh operation identifier automatically.

Broker deduplication can reduce some repeats, but it does not by itself prove that every external business effect is safe. Keep the guarantee scoped to the mechanism actually enforcing it.

Inspect identity and ordering

Confirm retries preserve the original event identifier and that conflicting payloads under the same identifier are detected. A replay tool should not quietly edit an event while retaining an identity consumers have already processed.

Review aggregate version handling if order matters. Delayed events may need rejection, buffering or a specific reconciliation rule. A timestamp sort in the publisher is not enough evidence of end-to-end ordering.

Check how long duplicate records are retained relative to possible replay and broker redelivery. Expiring them too soon can turn an old replay into a new effect.

Require the crash demonstration

Stop the publisher after broker acceptance and the consumer after its effect but before acknowledgement. Deliver again and inspect the target system.

Record the observed network attempts and business effects separately. The review passes when repeated delivery has a clear, tested outcome and operators know how to recover an incomplete effect without simply deleting the duplicate marker and hoping for the best.

Primary sources

AWS: SQS at-least-once deliveryAWS Builders' Library: idempotent APIs

References checked 11 September 2026.