# Decompose by transactions
<a name="decompose-transactions"></a>

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 | 
| --- | --- | 
|  [See the AWS documentation website for more details](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html)  | 

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

![Decomposing monoliths by transactions](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)


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.