Decomponi per transazioni

In un sistema distribuito, un'applicazione deve in genere chiamare più microservizi per completare una transazione aziendale. Per evitare problemi di latenza o problemi di commit in due fasi, puoi raggruppare i tuoi 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. Nella seguente tabella sono descritti i vantaggi e gli svantaggi di questo modello.

Vantaggi

Svantaggi

Tempi di risposta più rapidi. Non è necessario preoccuparsi della coerenza dei dati. Disponibilità migliorata.

È possibile impacchettare più moduli e questo può creare un monolite. Diverse funzionalità sono implementate in un unico microservizio anziché in microservizi separati, il che aumenta i costi e la complessità. I microservizi orientati alle transazioni possono crescere se il numero di domini aziendali e di dipendenze tra di essi è elevato. È possibile che versioni non coerenti vengano distribuite contemporaneamente per lo stesso dominio aziendale.

Nella figura seguente, il monolite assicurativo è suddiviso in più microservizi in base alle transazioni.

In un sistema assicurativo, una richiesta di risarcimento viene in genere contrassegnata a un cliente dopo essere stata inviata. Ciò significa che un servizio di reclami non può esistere senza un microservizio del Cliente. Vendite e clienti sono raggruppati in un unico pacchetto di microservizi e una transazione commerciale richiede il coordinamento con entrambi.