Descomponer según transacciones - AWS Guía prescriptiva

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
  • Tiempos de respuesta más rápidos.

  • No tiene que preocuparse por la coherencia de datos.

  • Mejora de la disponibilidad.

  • Se pueden empaquetar varios módulos y esto puede crear un monolito.

  • Se implementan múltiples funcionalidades en un único microservicio en lugar de microservicios separados, lo que aumenta el gasto y la complejidad.

  • Los microservicios orientados a las transacciones pueden crecer si el número de dominios empresariales y de dependencias entre ellos es elevado.

  • Es posible que se implementen versiones incoherentes al mismo tiempo para el mismo dominio empresarial.

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

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.