Transaction

With our foreign keys gone and the database split into smaller parts, we need to devise our own mechanisms for handling data integrity. Here, we need to factor in the possibility that not all services would successfully go through a transaction in the scope of their respective data stores.

A good example is a user ordering a specific product. At the time the order is being accepted, there is a sufficient quantity available to be ordered. However, by the time the order is logged, the Product service cannot log the orders for some reason. We don't know yet whether is was due to insufficient quantity or some other communication fault within the system. There are two possible options here. Let's discuss them one by one.

The first option is to try again and perform the remaining part of the transaction sometime later. This would require us to orchestrate the whole transaction in a way that tracks inpidual transactions across services. So every transaction that leads to transactions being performed for more than one service must be tracked. In case one of them does not go through, it deserves a retry. This might work for long-lived operations.

However, for other operations, this could cause a real problem. If the operation is not long-lived and you still decide to retry, the outcome will result in either locking out other transactions or making the transaction wait—meaning it is impossible to complete it. 

Another option that we can contemplate here is to cancel the entire set of transactions spread across various services. This means that a single failure at any stage of the entire set of transactions would result in the reversal of all the previous transactions.

This is one area where maximum prudence would be required, and it would be time well invested. A stable outcome is only guaranteed when the transactions are planned out well in any microservice-style architecture application.