{"id":4424,"date":"2018-01-10T21:21:37","date_gmt":"2018-01-11T05:21:37","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=4424"},"modified":"2023-06-23T09:00:33","modified_gmt":"2023-06-23T16:00:33","slug":"saga-pattern-implement-business-transactions-using-microservices-part","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/saga-pattern-implement-business-transactions-using-microservices-part\/","title":{"rendered":"Saga Pattern | Application Transactions Using Microservices \u2013 Part I"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Transactions are an essential part of applications. Without them, it would be impossible to maintain data consistency.<\/span><\/p>\n

One of the most powerful types of transactions is called a Two-Phase Commit, which is in summary when <\/span>the commit of a first transactions depends on the completion of a second.<\/span> It is useful especially when you have to update multiples entities at the same time, like confirming an order and updating the stock at once. <\/span><\/p>\n

However, when you are performing Microservices orchestration, for example, things get more complicated. Each service is a system apart with its own database, and you no longer can leverage the simplicity of local two-phase-commits to maintain the consistency of your whole system.<\/span><\/p>\n

When you lose this ability, RDBMS becomes quite a bad choice for storage, as you could accomplish the same \u201csingle entity atomic transaction\u201d but dozens of times faster by just using a NoSQL database<\/a> like Couchbase. That is why the majority of companies working with microservices are also using NoSQL.<\/span><\/p>\n

To exemplify this problem, consider the following high-level Microservices architecture of an e-commerce system:<\/span><\/p>\n

\"\"<\/p>\n

In the example above, one can\u2019t just place an order, charge the customer, update the stock and send it to delivery all in a single ACID transaction. To execute this entire flow consistently, you would be required to create a distributed transaction.<\/span><\/p>\n

We all know how difficult is to implement anything distributed, and transactions, unfortunately, are not an exception. Dealing with transient states, eventual consistency between services, isolations, and rollbacks are scenarios that should be considered during the design phase.<\/span><\/p>\n

Fortunately, we<\/span> already came up with some good patterns for it as we have been implementing distributed transactions for over 20 years now. The one that I would like to talk about today is called Saga pattern.<\/span><\/p>\n

The SAGA Pattern<\/b><\/h2>\n

A saga pattern<\/strong> is a sequence of local transactions where each transaction updates data within a single service. The first transaction in a saga is initiated by an external request corresponding to the system operation, and then each subsequent step is triggered by the completion of the previous one.<\/p>\n

One of the most well-known patterns for distributed transactions is called Saga. The first paper about it<\/span> was published back in 1987<\/span><\/a> and sagas have been a popular<\/span> solution since then.<\/span><\/p>\n

Using our previous e-commerce example, in a very high-level design a saga pattern implementation would look like the following:<\/span><\/p>\n

\"saga<\/p>\n

There are a couple of different ways to implement a saga transaction, but the two most popular are:<\/span><\/p>\n