En sistemas distribuidos, garantizar la consistencia de datos puede ser un gran desafío, especialmente cuando varios microservicios o componentes están involucrados. Aquí es donde entra en juego el Patrón Saga, una solución para manejar transacciones distribuidas de manera robusta y escalable. En este artículo, exploramos qué es el patrón Saga y como puede implementarse en AWS utilizando sus servicios.
¿Qué es Patrón Saga?
El Patrón Saga es un patrón de diseño utilizado para gestionar transacciones distribuidas en sistemas basados en microservicios. A diferencia de las transacciones tradicionales, que buscan consistencia a través de enfoques monolíticos, el Patrón Saga permite manejar la consistencia mediante una secuencia de transacciones independientes y coordinadas.
En el curso de AWS Skill Builder que lleve AWS: Diseño de Arquitecturas Basadas en Eventos, define al Patrón Saga de la siguiente manera:
Se utiliza para gestionar errores donde cada paso dentro de la transacción empresarial más grande incluye transacciones de compensación
que deshacen los cambios realizados por los predecesores.
Entonces podríamos definir que el Patrón Saga divide una transacción empresarial compleja en una serie de pasos más pequeños y autónomos, llamados transacciones locales. Si uno de estos pasos falla, se desencadenan eventos compensatorios.
Tipos de Sagas
Existen dos formas principales de implementar el Patrón Saga:
Sagas Coreografiadas
Aquí, los microservicios se comunican entre sí mediante eventos. Cada servicio escucha los eventos relevantes y realiza su tarea de forma autónoma. Este enfoque es altamente descentralizado, lo que reduce la dependencia de un coordinador central.Sagas Orquestadas
En este enfoque, un servicio central llamado "Orquestador" gestiona el flujo de las transacciones. Este orquestador se encarga de invocar a los microservicios en el orden adecuado y maneja los errores que puedan surgir.
Implementación del Patrón Saga con AWS
AWS ofrece diversas herramientas que facilitan la implementación del Patrón Saga en arquitecturas de microservicios. A continuación, exploraremos cómo puedes utilizar los servicios de AWS para implementar este patrón de manera efectiva:
- AWS Step Functions (Orquestación)
AWS Step Functions permite diseñar flujos de trabajo serverless que se adaptan perfectamente al modelo de orquestación del Patrón Saga. Con este servicio, puedes definir cada paso como una transacción local y gestionar tanto las acciones compensatorias como las excepciones en caso de errores.
- Amazon EventBridge (Coreografía)
Para este tipo de enfoque, Amazon EventBridge es ideal. Este servicio permite crear buses de eventos que conectan microservicios de forma descentralizada. Los eventos pueden activar acciones específicas en otros servicios sin necesidad de un orquestador central.
- Amazon SQS y SNS (Mensajería y Comunicación)
La mensajería entre microservicios es esencial para implementar Sagas. Amazon SQS y SNS son servicios de mensajería fiables que permiten que los microservicios se comuniquen de manera asíncrona, manteniendo el flujo de eventos necesario para las transacciones distribuidas.
- DynamoDB con Streams (Gestión de Estados)
Para registrar el estado de cada transacción dentro de una Saga, DynamoDB con Streams puede ser utilizado. Esto asegura que los datos de cada paso estén disponibles en tiempo real y listos para desencadenar acciones compensatorias en caso de fallos.
Caso de Uso: Orquestación
Diagrama: Patón saga para Transacciones Distribuidas en Orquestación de Orden de Pago
1. API Create Order
El usuario interactúa con una API para crear una orden. Esta API es el punto de entrada del sistema y captura los detalles iniciales de la solicitud.
2. Step Functions: Order Orchestration
La orquestación de la orden comienza con AWS Step Functions, que controla el flujo del proceso y asegura que cada paso se ejecute en el orden correcto.
3. Microservicio Order: Place Order
El primer paso en el flujo orquestado es invocar el microservicio de órdenes para procesar la solicitud inicial de creación de la orden. Aquí se puede validar información inicial o asignar un identificador único a la orden.
4. Lambda: Check Customer Credit Status
Se invoca una función Lambda para verificar el estado de crédito del cliente. Esta función interactúa con una base de datos (Credit Status DB) que contiene el historial o estado crediticio del cliente.
5. Credit Status DB: Check Status
La base de datos devuelve el estado del crédito del cliente. Dependiendo de la respuesta: Si el crédito es insuficiente, el flujo sigue la ruta de fallo. Si el crédito es válido, el flujo continúa para completar la orden.
6. DynamoDB Orden: Complete Order
Si el estado de crédito es satisfactorio, los detalles finales de la orden se registran en DynamoDB como orden completada.
7. Amazon SNS: Order Succeeded
Una notificación de éxito se envía a través de Amazon SNS para informar que la orden fue procesada correctamente.
8. Amazon SNS: Order Failed
Si la verificación de crédito falla, Step Functions emite un evento de fallo a través de Amazon SNS para notificar que la orden no pudo completarse.
Caso de Uso: Coreografía
Diagrama: Patón saga para Transacciones Distribuidas en Coreografía de Orden de Pago
1. Usuario interactúa con la API Create Order
El usuario realiza una solicitud para crear una orden a través de una API expuesta. Esta API recibe los detalles de la orden y actúa como el punto de inicio del flujo de eventos.
2. Order Service recibe la solicitud
El servicio de órdenes (Order Service) procesa la solicitud inicial y genera un evento llamado Event OrderCreated, indicando que la orden ha sido creada exitosamente. Este evento es publicado en EventBridge para que otros servicios interesados lo consuman.
3. Evento OrderCreated es procesado por RouteOrderCreatedToPayment
EventBridge enruta el evento OrderCreated hacia el servicio de pagos (Payment Service) a través de la regla RouteOrderCreatedToPayment. Este servicio se activa automáticamente al recibir el evento.
4. Payment Service procesa el pago
El servicio de pagos valida y procesa el pago asociado con la orden. Una vez completado, genera un nuevo evento llamado PaymentProcessed, indicando el estado del pago.
5. Evento PaymentProcessed es enrutado
EventBridge enruta el evento PaymentProcessed hacia la regla RouteOrderCreatedToPayment, activando la siguiente etapa del flujo de eventos.
6. Notificación de éxito de pago
Si el pago es exitoso, se genera un evento PaymentSuccessNotification que notifica el estado exitoso al sistema o a otros servicios interesados. Este evento podría enviar una confirmación al usuario o actualizar el estado en un sistema de seguimiento.
7. Manejo de fallos en el pago
En caso de que el pago falle, se genera un evento llamado PaymentFailedEvent. Este evento puede ser utilizado para iniciar procesos compensatorios, como reembolsos, reversión de inventarios o notificaciones de error al usuario.
8. Notificación de fallo en la orden
Si el fallo del pago afecta toda la orden, se genera el evento Order Failed Event. Este evento centraliza el estado fallido de la orden, actualiza su estado en DynamoDB como "fallida" y notifica a los servicios interesados para realizar acciones compensatorias o informar al usuario.
Ventajas del Patrón Saga con AWS
Escalabilidad: Gracias a los servicios serverless de AWS, se puede realizar una arquitectura altamente escalable.
Alta disponibilidad: AWS garantiza disponibilidad en todos los componentes clave de la implementación.
Costos controlados: Con un modelo Pay-as-you-go, puedes optimizar el costo de tu infraestructura.
Conclusión
El Patrón Saga es una herramienta poderosa para resolver los desafíos de consistencia en transacciones distribuidas, especialmente en arquitecturas de microservicios. Con los servicios de AWS, puedes implementar este patrón de manera eficiente y asegurar la resiliencia y escalabilidad del sistema.
Top comments (0)