The decision that matters
Write the business event and its pending delivery record in one database transaction. A worker processes pending entries with bounded retries and visible failure states. The worker should use a stable operation identifier to reduce duplicate effects. Keep the outbox record until the outcome is known and define a reconciliation path for uncertain delivery. This pattern improves recoverability but does not automatically guarantee exactly-once delivery.
A practical scenario
When an invoice is finalized, the transaction can store its final state and a pending email instruction together. If the mail service is temporarily unavailable, the invoice remains valid and the notification can be retried. Without a durable instruction, a crash between saving the invoice and sending the email may leave no record that the customer was supposed to be notified.
Before you ship
- Commit the business change and pending event together.
- Record attempt count, last error and next retry time.
- Provide an operator view for permanently failed or uncertain items.
A useful next step
Begin with one notification workflow and deliberately interrupt the worker. Confirm that processing resumes without losing the pending work. Design the operational view early so failed deliveries do not become invisible database rows.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.