Part 09 of 16 · Day 2 · Outbox, Inbox
Written but not sent
Problem and experience
We wrote it but did not send it
Changing data and sending an event are two operations. Anything can go wrong between them.
Two writes
- Write to DBOK
- Process crash
- Publish to brokernever happened
- Other servicesdo not know
From practiceWhen has it happened to you that data was saved but the message about it never arrived?
TakeawayThe event exists in the history, but nobody reacted to it.
What it means
The dual-write problem: two different technologies (database and broker) cannot be changed in one transaction.
Why we use it
Without a solution, systems drift apart on every random failure.
When it makes sense
Whenever a state change must lead to an event for other services.
Where it breaks
- The reverse order (broker first, then DB) produces an event about a change that never happened.
- Relying on crashes being rare.
Imagine
The application is saved, but the message about it never reaches the broker. Risk Service never hears about it and the application is left hanging.
Two writes are always an opportunity to drift apart.
Principle, application and exercise
Outbox and Inbox together
The message is written together with the change in one transaction. The publisher delivers it. The Inbox on the receiver side stops duplicates.
Sender
- Business changeapplication row
- Outboxrecord to send
- Publisherreads the Outbox
- Brokerduplicate possible
Recipient
- Inboxseen this eventId already?
- Effectexactly once
Trade-offAt-least-once delivery, an extra publisher, table clean-up. The receiver must be idempotent.
TakeawayThe Outbox guarantees sending. The Inbox guarantees the effect happens once.
What it means
Instead of publishing directly, we write the message to the Outbox table in the same transaction as the change. The publisher sends it and marks it. The receiver records processed IDs in the Inbox.
Why we use it
The message is not lost even if the process or the broker crashes. Duplicates are harmless.
When it makes sense
Whenever a state change must reliably lead to an event.
Where it breaks
- Outbox without Inbox: duplicates. Inbox without Outbox: losses.
- Not cleaning up sent records.
- Message order with multiple publishers.
Imagine
The broker is unavailable. The application is saved, the message waits in the Outbox and goes out as soon as the broker is back up.
Reliability does not come from nothing crashing, but from remembering what is still left to do.
Training for your team
Would you like this training for your team?
We run the training on your code and your domain problem. We agree the scope, dates and format with you.
Discuss the training →