Transactional Outbox

A Transactional Outbox stores a business data change and a durable outgoing message record in the same local database transaction. A separate process, the relay, reads these records and publishes them to a message broker. This closes the gap in which the database commit succeeds but the application never reaches the subsequent send attempt.

In a fictional example, support ticket S-27 changes to “closed”. The service saves the new status and event E-27 together. If the transaction fails, both changes roll back. If it commits and the service then crashes, the event record remains available for later publication.

Publication and processing are separate steps

If the relay publishes E-27 and crashes before recording that success, it may publish the message again. The recipient must handle repeated deliveries safely, for example with a Transactional Inbox. The outbox alone does not guarantee an exactly-once effect across the database, broker and recipient.

Define how pending records are found, failures become visible and, where needed, events for each ticket are published in order. Cleanup and restart rules also matter. CDC can provide a technical basis for the relay; capturing arbitrary row changes does not by itself define a business event.

Sources

• Chris Richardson — Transactional Outbox