Why you need the Outbox Pattern

A practical, basic Todo example

Let’s imagine we need to react when a user completes a todo. We decided to implement it with an event — and even we can have a single deployment unit at the moment — we want to be prepared for high scalability. Therefore in the future, we may split deployment units and integrate them via Message Bus.


I’m sure you know Murphy’s Law: “Anything that can go wrong will go wrong”. So let’s inspect our solution and find out what can go wrong.

“Just commit the transaction after the event is published”

Without any deeper investigation, you might try that one out. But it won’t help. Let’s try and analyze:

Outbox Pattern to the rescue

Luckily, we aren’t the only ones with such problems — and there are solutions for that. A quite “easy” way to solve such problems is to implement the Outbox Pattern. But you will see, even implementing such a relatively easy pattern will increase your “just publish an event” problem’s complexity.


As you have seen, “just publish an event” is only easy in the absence of Murphy. While starting with a really basic example, in the end, we touched on buzzwords like “eventual consistency”, “idempotency” and “deduplication”. You can go and implement an outbox by yourself (I will show a basic implementation in an upcoming post), or you just use a framework that cares about all that stuff. My personal favorite is NServiceBus.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store