The Outbox Pattern — [Notes]
--
The Outbox Pattern
- Simply, when your API publishes event messages, it doesn’t directly send them.
- Instead, the messages are persisted in a database table.
- After that, A job publish events to message broker system in predefined time intervals.
Basically The Outbox Pattern provides to publish events reliably. The idea of this approach is to have an “Outbox” table in the microservice’s database.
In this method, Domain Events are not written directly to a event bus. Instead of that, it is written to a table in the “outbox” role of the service that stores the event in its own database.
However, the critical point here is that the transaction performed before the event and the event written to the outbox table are part of the same transaction.
In example, when a new product is added to the system, the process of adding the product and writing the ProductCreated event to the outbox table is done in the same transaction, ensuring that the event is saved to the database.
The second step is to receive these events written to the outbox table by an independent service and write them to the event bus.
As you can see the above image, Order service perform their use case operations and update their own table and instead of publish an event, it is write another table this event record and this event read from another service and publish and event.
Why we use this Outbox Pattern ?
If you are working with critical data that need to consistent and need to accurate to catch all requests, then its good to use Outbox pattern.
If in your case, the database update and sending of the message should be atomic in order to make sure data consistency than its good to use outbox pattern.
For example the order sale transactions, it is already clear how important these data. Because they are about financial business. Thus, the calculations must be correct 100%.
To be able to access this accuracy, we must be sure that our system is not losing any event messages. So the outbox pattern should be applied this kind of cases.
So we should evolve our architecture with applying other Microservices Data Patterns in order to accommodate business adaptations faster time-to-market and handle larger requests.