Decompose by transactions - AWS Prescriptive Guidance

Decompose by transactions

In a distributed system, an application typically needs to call multiple microservices to complete one business transaction. To avoid latency issues or two-phase commit problems, you can group your microservices based on transactions. This pattern is appropriate if you consider response times important and your different modules do not create a monolith after you package them. The following table provides the advantages and disadvantages of using this pattern.

Advantages Disadvantages
  • Faster response times.

  • You don’t need to worry about data consistency.

  • Improved availability.

  • Multiple modules can be packaged together, and this can create a monolith.

  • Increased cost and complexity due to multiple functionalities being implemented in a microservice, instead of as a separate microservice.

  • Transaction-oriented microservices can grow if the number of business domains and dependencies among them is high.

  • Inconsistent versions might be deployed at the same time for the same business domain.

In the following illustration, the insurance monolith is broken down into multiple microservices based on transactions.


        Decomposing transactions pattern diagram

In an insurance system, a claim request is typically tagged to a customer after it is submitted. This means that a claims service cannot exist without a “Customers” microservice. "Sales" and "Customers" are packaged together in one microservice package, and a business transaction requires coordinating with both of them.