Tipo de patrón: Saga

Hola Habr! Les presento la traducción del artículo "Patrón: Saga" de Chris Richardson.

La situacion

Hay una aplicación a la que se aplicó el patrón Base de datos por servicio . Ahora cada servicio de aplicación tiene su propia base de datos. Algunas transacciones comerciales cubren varios servicios a la vez, por lo que se necesita un mecanismo para garantizar la coherencia de los datos entre estos servicios.

Por ejemplo: imaginemos que estamos desarrollando una tienda en línea donde un cliente tiene un límite de crédito. La aplicación debe garantizar que el nuevo pedido no exceda el límite de crédito del cliente. Dado que los pedidos y los clientes son bases de datos diferentes, la aplicación no puede usar transacciones ACID locales.

El problema

¿Cómo garantizar la coherencia de los datos entre los servicios?

Solución

Cada transacción comercial que abarca varios servicios debe implementarse como una saga.

Una saga es una colección de transacciones locales. Cada transacción local actualiza la base de datos y publica un mensaje o evento, iniciando la próxima transacción local en la saga. Si la transacción falló, por ejemplo, debido a una violación de las reglas comerciales, entonces la saga lanza transacciones compensatorias que revierten los cambios realizados por transacciones locales anteriores.

Hay dos formas de coordinar sagas:

• Coreografía: cada transacción publica eventos que desencadenan transacciones en otros servicios.
• Orquestación: un orquestador les dice a los participantes qué transacciones deben iniciarse.

Ejemplo: saga basada en coreografía

En una tienda en línea que utiliza una saga basada en coreografías, la creación de un pedido incluirá los siguientes pasos:

1. Order Service ( ) crea un Order () en estado pendiente (pendiente) y publica el evento OrderCreated ()
2. Customer Service ( ) recibe un evento e intenta reservar crédito para el pedido. Luego publica uno de dos eventos: CreditReserved () o CreditLimitExceeded ()
3. Order Service ( ) recibe un evento y cambia el estado del pedido a aprobado (confirmado) o cancelado (cancelado)

Ejemplo: saga orquestal

En una tienda en línea que utiliza una saga basada en la orquestación, la creación de un pedido incluirá los siguientes pasos:

1. Order Service ( ) crea un Order () en estado pendiente (pendiente) y crea una CreateOrderSaga ()
2. CreateOrderSaga () envía el comando ReserveCredit () al Customer Service ( ) al Customer Service ( )
3. Customer Service ( ) intenta reservar un préstamo para un pedido y envía una respuesta
4. CreateOrderSaga () recibe una respuesta y envía un ApproveOrder () o RejectOrder () en el Order Service ( )
5. Order Service ( ) cambia el estado del pedido a aprobado (confirmado) o cancelado (cancelado)

Saga tiene las siguientes ventajas

• Permite que una aplicación mantenga la consistencia de datos entre servicios sin usar transacciones distribuidas.

La saga tiene las siguientes desventajas

• El modelo de programación se está volviendo más complejo. Por ejemplo, los desarrolladores deben diseñar transacciones compensatorias que reviertan los cambios realizados anteriormente en la saga.