Software Architecture
Explica sagas como coordinación de transacciones distribuidas mediante pasos locales, eventos, compensaciones, idempotencia y estados intermedios observables.
Una saga coordina un proceso que atraviesa varias fronteras transaccionales mediante pasos locales, estados intermedios y compensaciones. No convierte el proceso en una transacción ACID global.
Cuando cada servicio o contexto posee sus datos, no existe una única transacción que cubra todo el flujo.
crear pedido
→ reservar stock
→ autorizar pago
→ confirmar pedidoUna saga mantiene el estado del proceso y define qué hacer cuando un paso falla.
Una operación distribuida puede quedar parcialmente completada:
stock reservado
+ pago no autorizadoSin diseño explícito, aparecen datos inconsistentes, recursos bloqueados y acciones manuales improvisadas.
La saga hace visibles:
Cada participante confirma su propio cambio:
Inventory transaction
→ crea reserva
Payments transaction
→ registra autorización
Orders transaction
→ confirma pedidoNo existe rollback automático entre ellos.
Una compensación es una acción de negocio que intenta neutralizar un efecto.
reservar stock
↔ liberar reservaNo borra la historia. Debe ser idempotente y puede fallar.
Un correo enviado no puede “desenviarse”. Una transferencia bancaria puede requerir devolución, no rollback.
Cada servicio reacciona a eventos:
OrderCreated
→ Inventory reserva
→ StockReserved
→ Payments autoriza
→ PaymentAuthorized
→ Orders confirmaFunciona mejor en procesos simples con pocas etapas y eventos claros.
Un orquestador persiste estado y envía comandos:
CheckoutSaga
1. reserveStock
2. authorizePayment
3. confirmOrderEl orquestador debe conocer secuencia, no internals de cada dominio.
type CheckoutSagaState =
| "started"
| "stock-reserved"
| "payment-authorized"
| "completed"
| "compensating"
| "failed-manual-review";También necesita:
El estado debe persistirse para sobrevivir reinicios.
pending.reserved.approved.CheckoutCompleted.ReleaseReservation.payment-failed.No se sabe si se autorizó.
payment-unknown.Este caso demuestra por qué timeout no es rechazo.
Cada paso debe clasificar errores:
Los retries usan la misma identidad para evitar duplicar efectos.
Una saga necesita deadlines de negocio:
reserva expira en 10 minutos
pago pendiente se revisa durante 24 horasUn timeout técnico de 3 segundos no equivale a expiración del proceso.
Si liberar stock falla:
compensating.La arquitectura debe contemplar el fallo del mecanismo de recuperación.
Mantener invariantes críticas dentro de una sola transacción local.
Separar compromiso temporal de confirmación definitiva.
Para excepciones raras y de alto riesgo puede ser más seguro.
Ofrece coordinación fuerte en entornos controlados, pero añade bloqueo, disponibilidad compuesta y soporte limitado. No es sustituto universal.
El estado y los comandos deben ser idempotentes.
Versiona saga y valida transición.
Optimistic locking o claim evita ejecución concurrente.
Retrásala hasta tener suficiente certeza o diseña reversión de negocio.
El código nuevo debe poder continuar estados históricos o migrarlos.
Mide:
Una vista operativa debe permitir buscar por order ID y correlation ID.
CQRS y Event Sourcing separa modelos de escritura y lectura, y estudia cuándo la historia de eventos debe convertirse en la fuente de verdad.