In a typical e-commerce scenario, a user places an order. The system does these two things:
- Insert the order into database (1st write operation)
- Send a notification to downstream systems such as payment service, fulfillment services, etc. (2nd write operation)
One of problems is that what if the system fails after inserting the order. Another one could be what if the notification fails. If you check the SLAs of building blocks, most offer 99.5% to 99.99% availability. These kinds of problems do happen in modern clouds.
Transactional Outbox Pattern is one of patterns resolving the dual write operations problem mentioned in the typical e-commerce scenario. The solution [1,3] is to:
- Replace the second write operation with an Outbox. Outbox is usually a database table in the same database for the 1st write operation. The 3rd party system such as Lambda can process the records asynchronously
- Wrap 1st write and 2nd write operation into one transaction
One of implementations of Outbox [1, 3] can be DynamoDB. This is interesting because it takes advantage of DynamoDB stream, an item-level event notification.
So when can we apply this pattern?
- Use it in a cause-effect relationship, and the effect end can be processed asynchronously
- Use it in two or more write operations as long as there is a chain of cause-effect relationship.
I would like to point out this pattern might also reduce the probability of deadlocks and increase performance
For more details, please refer to links below. Link #3 is an easy-to-follow walk-through. Highly recommend trying this.
References:
Jian Huang 