En el subcapítulo anterior vimos arquitecturas event-driven donde un proceso se reparte en muchos pasos independientes. Pero esto crea un problema delicado: ¿qué pasa si un proceso tiene varios pasos y uno de ellos falla a mitad? Por ejemplo, en un pedido se cobra el pago pero luego falla la reserva de stock. Quedaría un cliente cobrado sin producto: un estado inconsistente. El patrón Saga es la solución para coordinar procesos de varios pasos que pueden fallar, manteniendo todo coherente. Lo mencionamos brevemente en el subcapítulo 15.4; aquí lo vemos a fondo.

En un sistema de un solo bloque con una base de datos, hay un mecanismo clásico para esto: las transacciones. Una transacción dice «o se hacen todos los pasos, o no se hace ninguno»; si algo falla a mitad, todo se deshace automáticamente (rollback) y se queda como al principio. Es el principio de «todo o nada».

Pero en una arquitectura de microservicios (Capítulo 17) o serverless (Capítulo 28), cada paso lo hace un servicio distinto, con su propia base de datos. No hay una transacción única que los abarque a todos. Si el paso 3 de 5 falla, los pasos 1 y 2 ya se ejecutaron en otros servicios y no se deshacen solos:

Necesitas una forma de mantener la consistencia cuando una operación se reparte entre varios servicios y algo falla a mitad. Eso es la Saga.

El patrón Saga gestiona una operación de varios pasos repartidos entre servicios, de forma que, si un paso falla, los pasos anteriores se deshacen mediante acciones compensatorias (operaciones que cancelan lo ya hecho). En vez de un «rollback automático» (que no existe entre servicios), defines cómo deshacer cada paso, y la Saga las ejecuta en orden inverso si algo falla.

Analogía: una Saga es como reservar unas vacaciones por partes (vuelo, hotel y coche de alquiler, cada uno en una web distinta). Reservas el vuelo ✓, reservas el hotel ✓... y al ir a alquilar el coche, no hay disponibilidad ✗. Como no puedes ir sin coche, tienes que cancelar lo anterior: cancelas el hotel (y te devuelven el dinero) y cancelas el vuelo. Cada cancelación es una acción compensatoria que deshace una reserva. Al final, estás como al principio, sin reservas a medias. La Saga automatiza exactamente esa lógica de «si algo falla, deshago lo anterior paso a paso».

La diferencia esencial con una transacción tradicional: en una Saga no hay un rollback automático. En su lugar, tú defines explícitamente cómo deshacer cada paso (su acción compensatoria), y la Saga las ejecuta cuando hace falta. Esto requiere pensar, para cada paso, «¿cómo cancelo esto si luego algo falla?».

Por eso, al diseñar una Saga, para cada acción piensas también en su acción contraria: cobrar ↔ reembolsar, reservar ↔ liberar, crear ↔ borrar.

Hay dos formas habituales de coordinar una Saga, conectadas con lo que ya sabes:

• Por coreografía (con eventos): cada servicio reacciona a eventos (estilo event-driven del subcapítulo 28.1) y, si algo falla, emite un evento de fallo que dispara las compensaciones. No hay un «director»; los servicios se coordinan entre sí por eventos.
• Por orquestación (con un coordinador): un componente central dirige los pasos y, si uno falla, ordena las compensaciones. En AWS, la herramienta ideal para esto es Step Functions, que veremos en el siguiente subcapítulo (28.3): permite definir el flujo de pasos y qué hacer si cada uno falla, de forma visual y controlada.

• Cuando tienes un proceso de varios pasos repartido entre varios servicios (microservicios, serverless) y necesitas que sea consistente aunque algo falle a mitad.
• Procesos de negocio críticos como pedidos, pagos, reservas, donde dejar algo «a medias» sería un problema grave.

⚠️ Si tu operación cabe en un solo servicio con una base de datos, usa una transacción normal (es más simple). La Saga es para cuando la operación cruza varios servicios y no hay transacción común posible.

Ejemplo del mundo real: una plataforma de viajes procesa la reserva de un paquete completo: vuelo, hotel y traslado, cada uno gestionado por un servicio distinto (a veces de proveedores externos). Implementan una Saga: reservan el vuelo, luego el hotel, luego el traslado. Si en el último paso el traslado no está disponible, la Saga ejecuta las compensaciones: cancela el hotel y cancela el vuelo automáticamente, devolviendo al cliente a un estado limpio (sin reservas parciales ni cobros indebidos). El cliente recibe un «no ha sido posible completar la reserva» en vez de quedarse con un vuelo y un hotel pero sin forma de llegar. La Saga garantiza que el proceso es todo o nada, aunque por dentro sean muchos servicios independientes.

• En microservicios/serverless, una operación de varios pasos se reparte entre varios servicios sin una transacción común; si un paso falla a mitad, los anteriores ya se ejecutaron y quedaría un estado inconsistente.
• El patrón Saga gestiona esos procesos de forma que, si un paso falla, los anteriores se deshacen mediante acciones compensatorias (operaciones que cancelan lo ya hecho), volviendo a un estado consistente. Como cancelar por partes una reserva de vacaciones si algo no cuadra.
• La clave: no hay rollback automático como en una base de datos; tú defines cómo deshacer cada paso (cobrar↔reembolsar, reservar↔liberar).
• Se implementa por coreografía (eventos, estilo 28.1) o por orquestación (un coordinador como Step Functions, subcap. 28.3).
• Úsalo para procesos críticos de varios servicios (pedidos, pagos, reservas). ⚠️ Si todo cabe en un servicio con una base de datos, usa una transacción normal (más simple).

En el siguiente subcapítulo veremos la herramienta de AWS ideal para orquestar estos flujos de varios pasos de forma visual y controlada: Step Functions.