Decompose by transactions - AWS Prescriptive Guidance

Decompose by transactions

In a distributed system, an application typically has 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 explains 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.

  • Multiple functionalities are implemented in a single microservice instead of separate microservices, which increases cost and complexity.

  • 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 monoliths by transactions

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 coordination with both.