Sagas: flujos de trabajo de varios pasos entre servicios con compensación en lugar de rollback

Qué es

La página del patrón en microservices.io (citada) define una saga como una secuencia de transacciones locales: cada una actualiza la base de datos de un servicio y publica un mensaje o evento que desencadena la siguiente transacción local. Si una transacción local falla porque viola una regla de negocio, la saga ejecuta transacciones de compensación que deshacen los cambios realizados por los pasos anteriores. La coordinación es por coreografía (cada servicio reacciona a eventos) o por orquestación (un orquestador indica a los participantes qué hacer). La página enumera los inconvenientes: sin rollback automático, ya que las compensaciones se escriben a mano, y sin aislamiento, de modo que sagas concurrentes pueden leer el estado intermedio de otra.

El Azure Architecture Center (citado) añade un vocabulario útil: las transacciones compensables pueden deshacerse; una transacción pivote es el punto sin retorno, después del cual la saga debe avanzar hasta completarse; las transacciones reintentables siguen al pivote y son idempotentes, de modo que la saga siempre pueda terminar.

Por qué importa

Una vez que los datos viven en varios servicios, «crear pedido, reservar existencias, cobrar la tarjeta» no puede ser una sola transacción de base de datos. Sin una saga explícita, las rutas de fallo son implícitas: un cobro sin pedido, existencias reservadas para siempre.

Cómo aplicarlo

• Escribir el camino correcto como una lista de pasos y, junto a cada paso compensable, su compensación. Si un paso no tiene una compensación con sentido (un correo enviado, un pago capturado), es el pivote o debe ir después de él.
• Ordenar los pasos de modo que los más propensos a fallar por reglas de negocio vayan primero y el paso irreversible vaya al final.
• Hacer que cada paso y cada compensación sean idempotentes y estén identificados con el id de la saga, porque los mensajes se entregan al menos una vez.
• Persistir el estado de la saga (qué paso tuvo éxito) para que un orquestador reiniciado retome en lugar de reiniciar; publicar los eventos desencadenantes mediante un outbox.
• Manejar deliberadamente la brecha de aislamiento: marcar los registros como pendientes hasta que la saga se complete, y hacer que quienes lean traten en consecuencia el estado pendiente.
• Fijar un tiempo límite por paso y definir qué ocurre al expirar (compensar o escalar a una persona).

Trampas

Una compensación es una nueva acción de negocio, no un rollback: reembolsar no equivale a anular el cobro, y puede fallar por sí misma y necesitar reintento. La página de Azure describe la coreografía como adecuada para flujos de trabajo simples con pocos servicios y señala que el flujo se vuelve confuso a medida que se añaden pasos; un orquestador con una máquina de estados visible es más fácil de operar en sagas más largas. Las sagas no eliminan la necesidad de que el último paso sea idempotente ante reintentos.