Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Descomponer según transacciones En un sistema distribuido, una aplicación normalmente tiene que llamar a varios microservicios para completar una transacción comercial. Para evitar problemas de latencia o de confirmación en dos fases, puede agrupar los microservicios en función de las transacciones. Este patrón es adecuado si considera que los tiempos de respuesta son importantes y sus distintos módulos no crean un monolito después de empaquetarlos. En la siguiente tabla se explican las ventajas y desventajas de usar este patrón. **** | Ventajas | Desventajas | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) | En la siguiente ilustración, el monolito de los seguros se divide en varios microservicios en función de las transacciones. ![\[Descomposición de los monolitos por transacciones\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png) En un sistema de seguros, una solicitud de reclamación normalmente se etiqueta a un cliente después de haberla enviado. Esto significa que un servicio de reclamaciones no puede existir sin un microservicio del *Cliente*. Las *ventas* y los *clientes* se agrupan en un solo paquete de microservicios, y una transacción comercial requiere la coordinación con ambos.