Décomposer par transactions

Dans un système distribué, une application doit généralement appeler plusieurs microservices pour effectuer une transaction commerciale. Pour éviter les problèmes de latence ou les problèmes de validation en deux phases, vous pouvez regrouper vos microservices en fonction des transactions. Ce modèle est approprié si vous considérez que les temps de réponse sont importants et que vos différents modules ne créent pas de monolithe après les avoir empaquetés. Le tableau suivant explique les avantages et les inconvénients liés à l'utilisation de ce modèle.

Avantages

Inconvénients

Des temps de réponse plus rapides. Vous n'avez pas besoin d'être inquiet pour l'uniformité des données. Disponibilité améliorée.

Plusieurs modules peuvent être empaquetés ensemble, ce qui peut créer un monolithe. De multiples fonctionnalités sont mises en œuvre dans un seul microservice au lieu de microservices distincts, ce qui augmente les coûts et la complexité. Les microservices orientés vers les transactions peuvent se développer si le nombre de domaines d'activité et de dépendances entre eux est élevé. Des versions incohérentes peuvent être déployées en même temps pour le même domaine d'activité.

Dans l'illustration suivante, le monolithe de l'assurance est décomposé en plusieurs microservices basés sur des transactions.

Dans un système d'assurance, une demande de réclamation est généralement associée à un client après sa soumission. Cela signifie qu'un service de gestion des sinistres ne peut exister sans un microservice destiné aux clients. Les ventes et les clients sont regroupés dans un seul package de microservices, et une transaction commerciale nécessite une coordination entre les deux.