Outbox Pattern
Problem
- An ASP.NET Core API saves an order to the database, then publishes an OrderPlaced event to a message queue.
- The process crashes between the two steps. The order committed, but the event was never sent.
- Nothing downstream ever finds out the order was placed. Billing, shipping, and notifications all stay silent.
Two steps, and only the first one is guaranteed.
Solution
Outbox Pattern
- Save the order and the event together, in one database transaction. The event becomes a row in an outbox table.
- A background publisher reads unsent rows, publishes them to the queue, and marks them sent.
- A crash before the commit loses both together. A crash after the commit loses neither.
The write and the event either both happen, or neither does. That guarantee is the outbox pattern.
Analogy
You sign a contract and, in the same motion, drop a copy in the office outbox tray. The mail room clears the tray every hour and posts whatever it finds.
You never run to the post office yourself between meetings, and a signed contract never exists without its copy waiting in the tray.
The outbox table is that tray, sitting inside your database.
