Let’s look at the Outbox Pattern.
The Outbox Pattern in microservices solves a common problem. Say we have a system that processes an order, and want that event to trigger an email.
So we put the payment, order processing, and email sending in a database transaction. They each succeed if they all succeed, or else we roll back. But what happens when the payment and order succeed; do we wait for the email to send before deciding that the transaction succeeded? What it the email fails; do we roll back the payment and order? Or maybe we can’t use a transaction?
We can, with the Outbox Pattern. Instead of sending the email, we record the email message in an outbox table inside the transaction, allowing it to conclude. A separate process then publishes these messages with the appropriate retries and idempotency.
This explains how a user can order an item even when other processes like the email provider are offline. The email process functions independently of the ordering.