Outbox Pattern: Reliable Events From Databases

The outbox pattern fixes the dual-write problem

Many applications need to update a database and publish an event. For example, create an order and publish OrderCreated, update an invoice and publish InvoicePaid, or change a user role and publish RoleChanged. The dangerous part is doing two separate writes: one to the database and one to a message broker. If one succeeds and the other fails, the system becomes inconsistent.

The outbox pattern stores the business change and the event record in the same database transaction. A separate publisher later reads the outbox table and sends events to the broker. This makes event publication reliable because the event is committed with the data change.

The outbox table is a delivery queue

An outbox record usually contains an event ID, aggregate ID, event type, payload, creation time, publish status, retry count, and error details. A worker polls or streams new outbox records, publishes them, and marks them as sent. If publishing fails, the record remains available for retry.

This pattern does not guarantee consumers process the event exactly once. It makes sure the event is not lost between the database and broker. Consumers should still be idempotent because publishers may retry after uncertain failures.

• Write business data and outbox events in one transaction.
• Use stable event IDs so consumers can deduplicate.
• Monitor unpublished outbox records and retry failures.
• Clean up or archive old outbox records with a retention policy.

Polling is simple, streaming is faster

A polling publisher is easy to build and often good enough. It periodically queries unsent records, publishes a batch, and updates status. The tradeoff is extra database reads and possible delay. For many products, a short delay is acceptable.

Change data capture can publish outbox records by reading database logs. This can reduce polling and improve throughput, but it adds infrastructure complexity. Start with the simplest approach that meets reliability and latency needs.

Event design still matters

The outbox pattern handles delivery reliability, not event quality. Events should have clear names, versioned schemas, safe payloads, and documented meaning. Do not publish raw database rows if downstream teams need business facts. A good outbox event tells consumers what happened in language they can depend on.

Privacy and security also apply. If an outbox payload contains personal data, it may be copied to brokers, logs, data lakes, and downstream services. Include only what consumers need and apply retention rules.

Reliable events make systems easier to trust

The outbox pattern is popular because it addresses a real failure mode without requiring distributed transactions. It gives teams a practical way to connect database state and event-driven workflows. When paired with idempotent consumers and monitoring, it makes integrations more dependable under ordinary production failure.