Esta es la segunda lección de nuestra serie. En la primera, definimos el problema de microservicios distribuidos en nuestra empresa hipotética Simply Order, revisamos posibles enfoques para transacciones distribuidas y explicamos por qué Two-Phase Commit 2PC no es adecuado para microservicios, y cómo el patrón Saga resuelve esas limitaciones.
En esta entrega pasamos de la idea al código: diseñaremos e implementaremos la primera versión de nuestro flujo Saga utilizando Temporal como orquestador.
Antes de programar: cómo pensar una saga
1) Empieza por la transacción de negocio. Nuestro caso Place Order sigue esta secuencia: crear pedido, reservar inventario, autorizar pago, completado. La lógica de negocio exige ejecutar los pasos en ese orden.
2) Dibuja la máquina de estados. El pedido recorrerá estados como OPEN, PENDING, INVENTORY_RESERVED, PAYMENT_AUTHORIZED, COMPLETED. En caso de error, clasificaremos con precisión: INVENTORY_FAILED, PAYMENT_FAILED o FAILED_UNKNOWN. Esto nos permitirá observar, compensar y auditar correctamente.
3) Por qué Orchestración Saga. La coreografía por eventos es simple y útil en flujos cortos y lineales, pero a medida que el proceso crece, aparecen ramificaciones y dependencias que convierten el intercambio de eventos en un spaghetti difícil de trazar y evolucionar. Por ello, y pese a que nuestro flujo inicial es sencillo, optamos por Orchestración Saga para mantener claridad, control de errores y extensibilidad.
Qué es Temporal. Temporal es una plataforma open source de orquestación de workflows que permite escribir procesos fiables y de larga duración en código. Gestiona automáticamente reintentos, estado, timeouts y compensaciones para que te centres en la lógica de negocio. No se limita a sagas: es una plataforma generalista de workflows y el patrón Saga es solo una de las muchas posibilidades.
Implementación del flujo. Definimos el Workflow de Pedido como una secuencia clara, separando responsabilidades: 1 actualizar el estado a PENDING, 2 invocar al servicio de inventario para reservar y registrar su compensación liberar inventario si aplica, 3 actualizar a INVENTORY_RESERVED, 4 invocar al servicio de pagos para autorizar y registrar su compensación anular pago si aplica, 5 actualizar a PAYMENT_AUTHORIZED, 6 finalizar marcando COMPLETED. Las compensaciones se registran inmediatamente después de que un paso se complete con éxito, garantizando que si ocurre un error posterior solo se compensen las acciones efectivamente realizadas.
Actividades y no bloqueo. Aunque el código de cada actividad parezca síncrono por ejemplo, una llamada HTTP al servicio de inventario con cabeceras de idempotencia, Temporal ejecuta las actividades en Workers separados, de modo que el workflow permanece no bloqueante y determinista. Además, definimos políticas de reintentos y timeouts, por ejemplo hasta 5 intentos con backoff exponencial y un start to close de 2 minutos para cada actividad. En escenarios reales, una actividad puede ejecutarse indefinidamente con reintentos automáticos hasta tener éxito, salvo que configures lo contrario.
Componentes clave de Temporal. Workflow code orquestación determinista sin I O externa. Activity code efectos colaterales como llamadas a servicios, BDs o APIs. Worker proceso que ejecuta workflows y actividades y hace polling a una Task Queue. Temporal Server que almacena el historial de eventos, entrega tareas y aplica reintentos y timeouts. Task Queue cola lógica que desacopla servidor y workers. Client que inicia workflows, envía señales y atiende consultas. Persistencia donde el servidor guarda el historial y el estado.
Configuración técnica. En el proyecto incorporamos el SDK de Temporal, definimos el Client y los Workers y registramos el Workflow y las Activities. Identificamos el workflow mediante las anotaciones de interfaz y método, y las actividades mediante su interfaz anotada. De esta manera el Worker puede registrar la implementación y el servidor programar las tareas de actividad y emparejarlas con el código correcto en el Worker.
Gestión de errores y estados. En el catch del workflow invocamos saga compensations en orden inverso por ejemplo anular pago y luego liberar inventario y finalmente clasificamos el error para actualizar el estado del pedido con precisión. Esta estrategia aporta trazabilidad, resiliencia y consistencia eventual sin bloquear el proceso completo.
Resumen. En esta lección convertimos la teoría del patrón Saga en un flujo de pedidos real sobre Temporal, con estados claros, compensaciones y manejo de errores. En próximas entregas añadiremos cancelaciones, envíos y otros casos del mundo real.
Sobre Q2BSTUDIO. Somos una empresa de desarrollo de software que crea aplicaciones a medida y software a medida para cadenas de valor críticas, con foco en orquestación de microservicios, automatización de procesos, inteligencia artificial e integración con servicios cloud aws y azure. Diseñamos soluciones escalables y seguras con ciberseguridad desde el diseño, y conectamos datos para ofrecer servicios inteligencia de negocio con power bi, agentes IA e ia para empresas.
Si buscas acelerar la entrega de valor con un orquestador como Temporal y una arquitectura preparada para crecer, nuestro equipo puede ayudarte desde la definición del workflow hasta la puesta en producción. Descubre cómo abordamos proyectos de aplicaciones a medida en desarrollo de software multiplataforma y cómo automatizamos flujos complejos con tecnología y buenas prácticas en automatización de procesos.
Palabras clave para empresas que quieren escalar con tecnología: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi. Contáctanos y llevemos tu orquestación Saga y tus microservicios al siguiente nivel.