A service often needs to do two things together: update its database and publish an event. That sounds simple, but the database and the message broker are two separate systems. A normal local database transaction cannot cover both.

If the service commits first and then publishes, it can crash in the gap. If it publishes first and then commits, the database write can fail after the event is already out. This is the dual-write problem, and the Outbox pattern is the standard way to handle it.

The pattern avoids the unsafe two-system write in the request path. The service writes the business change and an event record into the same database transaction. They commit together or roll back together. Later, a separate relay reads the outbox table and publishes the event to the broker.

The database remains the trusted record. The broker receives events that describe facts already committed in the database.

This chapter explains how the Outbox pattern works, what it guarantees, and what you still need to design carefully.