In this post, I will talk about the Outbox pattern for Microservice Architecture. There are various design patterns that you will need as you build scalable microservices.  An outbox pattern is one such pattern in your toolbox.

As you build more services, you will notice how and when to use such patterns. Other than design patterns, you will need communication patterns between microservices.

When to use Outbox Pattern?

In many scenarios, a microservice (for example Microservice A) will receive data from a client or another microservice.  This microservice A has to save and process the data and then it needs to send processed data to another microservice for further processing. This will look like below:

Basically, Microservice A has to process and send data in the same transaction. This can be erroneous in many cases if Microservce A saved the data in DB, but failed to send it to another microservice.

In many eCommerce platforms, an Order Service will receive order data and it needs to send order details and calculated amount to Invoice Service to bill for that transaction. In such cases, it’s not the best design to save and send the data in the same transaction.  That’s where the Outbox pattern comes into play. We will talk about this pattern in a further section.

What is Outbox Pattern?

When a microservice receives critical data, it persists the data in a database. And now the data is available to be published for another microservice that requires it.

You can schedule a job that regularly publishes this critical data to another microservice. This way, we separate the two processes of saving and publishing.

It will look like below:

As you can see above, Microservice A stores the transaction in a database. A regularly scheduled job takes that data from transactions and publishes it as a domain event to the message broker. Microservice B reads that and processes it further.

There is another option with Outbox Pattern. When Microservice A stores the data transaction data for an entity in the database, it can copy the same data into another table called Outbox. The regularly scheduled job will pick up domain event from outbox table and publishes them to the message broker.

Why to use this pattern?

If you are working with critical data and it needs to be consistent across services, it is beneficial to use the outbox pattern. The pattern assures data consistency by separating the processes of saving and publishing.

Another advantage of the outbox pattern is if a microservice did not receive or could not process any events, you will always have that event stored in the outbox table to reprocess.

Conclusion

In this post, we discussed Outbox Pattern. It’s one of the simple patterns to learn about and use where you need data consistency across services.

If you are looking for a consultation about microservices design, I am available to offer my consultation on a need basis.