Outbox Pattern for Microservices Architectures

In this article, we are going to talk about Design Patterns of Microservices architecture which is The Outbox Pattern. As you know that we learned practices and patterns and add them into our design toolbox. And we will use these pattern and practices when designing e-commerce microservice architecture.

By the end of the article, you will learn where and when to apply Outbox Pattern into Microservices Architecture with designing e-commerce application system.

Step by Step Design Architectures w/ Course

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.

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.

Step by Step Design Architectures w/ Course

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.