Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Scomponi per transazioni
<a name="decompose-transactions"></a>

In un sistema distribuito, un'applicazione in genere deve chiamare più microservizi per completare una transazione commerciale. Per evitare problemi di latenza o problemi di commit in due fasi, puoi raggruppare i microservizi in base alle transazioni. Questo schema è appropriato se consideri importanti i tempi di risposta e i diversi moduli non creano un monolite dopo averli impacchettati. La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo di questo modello.


****  

| Vantaggi | Svantaggi | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html)  | 

Nella figura seguente, il monolito assicurativo è suddiviso in più microservizi basati sulle transazioni. 

![\[Scomposizione dei monoliti per transazioni\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)


In un sistema assicurativo, una richiesta di sinistro viene in genere contrassegnata a un cliente dopo l'invio. Ciò significa che un servizio di gestione dei reclami non può esistere senza un microservizio *Customers*. *Le vendite* e *i clienti* sono raggruppati in un unico pacchetto di microservizi e una transazione commerciale richiede il coordinamento con entrambi.