La lección anterior terminó con la pregunta más incómoda del módulo. En el monolito de 01-06, crear un pedido era una transacción: BEGIN, insertar el pedido, descontar el stock, registrar el cobro, COMMIT; si cualquier paso fallaba, ROLLBACK y como si nada hubiera pasado. Hoy esa misma operación cruza tres servicios con tres bases de datos, km0_pedidos, km0_inventario y km0_pagos, cada una replicada como vimos en 03-04, y ninguna transacción de PostgreSQL abarca las tres. Si el cobro de Marc es rechazado después de haber descontado el último queso-curado, alguien tiene que devolverlo al stock; si pedidos muere entre el descuento y el cobro, el pedido de Marc queda en un limbo que nadie ha diseñado.

Esta lección presenta las dos familias de respuesta. La primera intenta conservar la atomicidad del monolito con un protocolo de commit en dos fases (2PC), que PostgreSQL soporta con PREPARE TRANSACTION; veremos cómo funciona, por qué bloquea cuando el coordinador cae y por qué los microservicios lo evitan. La segunda renuncia a la atomicidad y la sustituye por una saga: una secuencia de transacciones locales, cada una con su compensación, coordinada por eventos (coreografía) o por un orquestador con estado persistido. Implementaremos el orquestador de pedidos en Python, con su tabla sagas en km0_pedidos, y lo veremos compensar el stock cuando pagos rechaza a Marc; después escribiremos la misma saga como coreografía con consumidores Kafka y compararemos ambas. Terminaremos con lo que las sagas pierden respecto a ACID (el aislamiento) y las contramedidas, y con el patrón TCC. La conclusión cierra el Módulo 3 y abre el Módulo 4, dedicado a dónde y cómo se almacenan físicamente los datos que ya sabemos replicar y coordinar.

1. ACID y la transacción que ya no existe
2. Commit en dos fases (2PC)
3. Por qué 2PC bloquea, y 3PC
4. 2PC real: XA y PREPARE TRANSACTION en PostgreSQL
5. Por qué los microservicios evitan 2PC
6. Sagas: transacciones locales con compensaciones
7. Coreografía: la saga como cadena de eventos
8. Orquestación: saga_pedido.py con estado persistido
9. Tabla coreografía vs orquestación
10. Compensaciones, idempotencia y el aislamiento perdido; TCC
11. Errores comunes y consejos
12. Ejercicios
13. Conclusión

Recordemos qué prometía la transacción del monolito, porque cada letra de ACID va a tener un destino distinto en el sistema distribuido:

La transacción original, en km0/sql/monolito.sql de 01-06, era esencialmente esta:

Si el UPDATE no afectaba a ninguna fila (sin stock) o la pasarela de pago fallaba, un ROLLBACK deshacía todo. Hoy las tres sentencias viven en tres servicios, y la pregunta es qué sustituye al COMMIT.

El commit en dos fases (Gray, 1978) es el protocolo clásico de commit atómico: hacer que varios participantes, cada uno con su propia transacción local, confirmen todos o aborten todos. Sus roles:

• Coordinador: el proceso que dirige el protocolo (en nuestro caso lo sería pedidos, o un gestor de transacciones externo).
• Participantes: las bases de datos o servicios con una transacción local abierta (km0_pedidos, km0_inventario, km0_pagos).

Fase 1, prepare. El coordinador pregunta a cada participante "¿puedes confirmar?". Un participante que responde sí se compromete de forma irrevocable: escribe la transacción en disco de manera que pueda confirmarla aunque se reinicie, y mantiene sus bloqueos hasta que llegue la decisión. Un participante puede responder no (violación de restricción, sin stock, tarjeta rechazada), y entonces la decisión será abortar.

Fase 2, commit o abort. Si todos han dicho sí, el coordinador escribe la decisión en su propio log (este es el punto de no retorno: a partir de aquí la transacción está confirmada aunque nadie lo sepa aún) y envía commit a todos; si alguno dijo no, envía abort. Los participantes ejecutan la decisión y responden; el coordinador puede reintentar la fase 2 tantas veces como haga falta, porque un participante en estado "preparado" siempre puede obedecer.

La corrección del protocolo se apoya en dos promesas: el participante preparado nunca decide por su cuenta, y el coordinador nunca olvida una decisión tomada. Ambas exigen escrituras en disco (fsync) en el momento adecuado, y por eso 2PC cuesta al menos dos viajes de red y dos fsync por participante, además del trabajo en sí.

El punto débil está en la palabra "nunca" de la primera promesa. Imagina que los tres participantes han respondido sí y el coordinador muere justo después, antes de enviar la decisión (o incluso antes de escribirla). Los participantes están en estado preparado: con los bloqueos retenidos (la fila de stock de queso-curado bloqueada, el pedido de Marc invisible para las lecturas que necesitan el bloqueo) y sin poder decidir nada:

• No pueden abortar, porque quizá el coordinador había decidido commit y ya se lo había dicho a otro participante.
• No pueden confirmar, porque quizá otro participante dijo no.
• Preguntar a los otros participantes no siempre ayuda: si todos están preparados, ninguno sabe la decisión.

Solo pueden esperar a que el coordinador vuelva y lea su log. Si el coordinador tarda una hora, esa fila de stock está bloqueada una hora; es lo que se llama el bloqueo (blocking) de 2PC, y es un problema de disponibilidad en el sentido de 03-02: el sistema sacrifica A (participantes vivos que no pueden avanzar) para preservar la atomicidad. En la práctica, los operadores acaban resolviendo transacciones preparadas a mano (decidiendo commit o abort por inspección), lo que se llama heurística, con el riesgo evidente de decidir distinto de lo que decidió el coordinador.

El commit en tres fases (3PC, Skeen, 1981) añade una fase intermedia (pre-commit) para que los participantes puedan deducir la decisión sin el coordinador, y elimina el bloqueo... a costa de asumir una red síncrona con retrasos acotados y sin particiones, precisamente lo que 01-02 y 03-02 nos dijeron que no tenemos. Con una partición, 3PC puede llevar a un lado a confirmar y a otro a abortar. Por eso casi nadie lo usa, y por eso la solución moderna al bloqueo de 2PC es hacer al coordinador tolerante a fallos con consenso (03-03): Spanner, por ejemplo, ejecuta 2PC entre grupos Paxos, de modo que el "coordinador" es un grupo replicado que no muere. Es correcto y es carísimo.

El estándar XA (X/Open, años 90) define la interfaz entre un gestor de transacciones y los recursos participantes (bases de datos, colas); Java lo expone como JTA, y los servidores de aplicaciones clásicos lo usaban para transacciones que abarcaban una base de datos y una cola JMS. PostgreSQL implementa el lado del participante con tres sentencias: PREPARE TRANSACTION 'id' (fase 1: la transacción actual queda preparada y sobrevive a reinicios), COMMIT PREPARED 'id' y ROLLBACK PREPARED 'id' (fase 2). Requiere max_prepared_transactions > 0 en postgresql.conf (por defecto es 0, deliberadamente). Un coordinador mínimo en Python entre km0_inventario y km0_pedidos:

Para ver el bloqueo con tus propios ojos, mata el proceso (o pon un sys.exit()) justo después de la fase 1 y consulta en cualquiera de las bases de datos:

La transacción preparada sobrevive incluso a un reinicio del servidor, y mientras exista, la fila de queso-curado está bloqueada: cualquier otro UPDATE sobre ella espera indefinidamente. Solo un COMMIT PREPARED o ROLLBACK PREPARED explícito la libera, y decidir cuál es la resolución heurística del apartado 3. (Lo mismo que PREPARE TRANSACTION existe en MySQL con XA PREPARE, y en colas como ActiveMQ o IBM MQ; Kafka no participa en XA, y RabbitMQ tampoco, lo que ya limita mucho su uso con nuestra arquitectura.)

Con 2PC funcionando en dos líneas de SQL, la pregunta natural es por qué no usarlo para el pedido de Marc. Las razones son todas prácticas:

1. Acoplamiento: el coordinador necesita acceso transaccional directo a las bases de datos de inventario y pagos, lo que rompe la regla "cada servicio es dueño de sus datos" de 01-06. La alternativa, que cada servicio exponga operaciones prepare/commit/abort por gRPC, es posible pero convierte a cada servicio en un gestor de recursos XA, con sus logs, su recuperación y sus transacciones huérfanas.
2. Disponibilidad: el bloqueo del apartado 3 significa que la caída de pedidos (el coordinador) deja bloqueadas filas en inventario y pagos. Un fallo en un servicio se convierte en un fallo en tres: lo contrario del aislamiento de fallos que buscábamos al separar los servicios (01-03).
3. Latencia y rendimiento: dos fases con fsync en cada participante, con los bloqueos retenidos durante todo el intercambio, limitan el número de pedidos por segundo a lo que tolere el participante más lento.
4. Heterogeneidad: pagos habla con una pasarela externa (02-05) que no participa en ningún 2PC: no se puede "preparar" un cobro con tarjeta. Kafka y Redis tampoco son participantes XA. En cuanto un paso no es una base de datos relacional, 2PC ya no cubre la operación completa.
5. Operación: las transacciones preparadas huérfanas requieren intervención manual, y los equipos que han operado XA en producción suelen describirlo como la fuente más frecuente de incidentes nocturnos.

2PC sigue siendo la herramienta correcta dentro de un sistema que lo controla todo (una base de datos distribuida como Spanner o CockroachDB lo usa entre sus propios nodos, con coordinador replicado por consenso), pero entre servicios independientes la industria ha convergido en la alternativa que renuncia a la atomicidad: la saga.

El patrón saga (García-Molina y Salem, 1987, para transacciones de larga duración en una sola base de datos) se reformuló para microservicios hace una década. Una saga es una secuencia de transacciones locales T1, T2, ..., Tn, cada una en un servicio y confirmada por separado, tal que:

• Si todas tienen éxito, la operación de negocio está completa.
• Si Ti falla, se ejecutan las transacciones compensatorias C(i-1), ..., C1 de las que ya se habían confirmado, en orden inverso, dejando el sistema en un estado semánticamente equivalente al inicial (no idéntico: el pedido cancelado sigue existiendo como registro, el cobro reembolsado aparece en el extracto de Marc).

Para el pedido de Kilómetro Cero:

Los pasos se clasifican en tres tipos, y el orden en que se colocan importa:

• Compensables: tienen compensación (T1, T2). Van al principio.
• Pivote: el paso que decide si la saga tendrá éxito; una vez confirmado, la saga no puede abortar (T3, el cobro: si se cobra, el pedido sale). Suele ser el paso con más probabilidad de fallar o el que no puede compensarse limpiamente, y se coloca lo más tarde posible.
• Reintentables: después del pivote, pasos que no pueden fallar de forma permanente, solo transitoria, y se reintentan hasta que funcionen (T4).

Hay dos formas de coordinar quién ejecuta cada paso y cada compensación, y son el objeto de los dos apartados siguientes.

En una saga coreografiada no hay coordinador: cada servicio reacciona a los eventos de los demás y publica los suyos, por el tópico pedidos.eventos de 02-04 y 02-05 (o tópicos por servicio). La cadena de eventos del pedido:

Cada servicio implementa su parte como un consumidor idempotente de 02-05 que, en la misma transacción, aplica el efecto local y escribe el evento siguiente en su outbox. El fragmento de inventario, que reacciona a pedido.creado y a pago.rechazado:

(psycopg.Rollback es la excepción que conn.transaction() captura para deshacer el bloque sin propagarla; aquí la reutilizamos como señal de "sin stock". En el mismo estilo, pagos consume stock.reservado, cobra con la Idempotency-Key de 02-05 y publica pago.confirmado o pago.rechazado; y pedidos consume pago.confirmado para T4 y stock.insuficiente/stock.liberado para C1.)

La coreografía es atractiva por su simplicidad aparente: no hay ningún componente nuevo, solo consumidores. Sus problemas aparecen al crecer: para saber en qué estado está el pedido de Marc hay que reconstruirlo a partir de eventos repartidos por tres tópicos; añadir un paso (por ejemplo, "asignar repartidor" entre el cobro y la confirmación) obliga a tocar varios servicios; y las dependencias cíclicas (pedidos escucha a pagos, que escucha a inventario, que escucha a pedidos) hacen difícil razonar sobre el flujo completo. Con tres pasos es manejable; con ocho, no.

En una saga orquestada, un componente, el orquestador, sabe cuál es la secuencia, invoca cada paso (por gRPC síncrono o publicando comandos), interpreta la respuesta y decide el siguiente paso o la compensación. El orquestador es una máquina de estados cuyo estado se persiste tras cada transición, de modo que si el proceso muere, otra instancia (o la misma al reiniciar) la retoma donde estaba. En Kilómetro Cero vive en pedidos, porque es el servicio dueño del concepto "pedido" y quien inicia la operación, con esta tabla en km0_pedidos:

El orquestador define los pasos como pares (acción, compensación), avanza persistiendo, y compensa hacia atrás si un paso falla de forma permanente. Para que el ejemplo sea ejecutable sin infraestructura, los clientes de inventario y pagos y el repositorio de sagas tienen versiones simuladas; las reales serían el stub gRPC de 02-03, el cliente de la pasarela de 02-05 y psycopg sobre la tabla anterior.

Salida:

Los puntos importantes del código, para quien lo lea por primera vez:

• Persistir antes de seguir. _transicion guarda la saga en cada cambio de estado, y paso_actual se incrementa solo tras el éxito del paso. Si el proceso muere entre paso.accion(saga) y _transicion, al reiniciar continuar(saga_id) volverá a ejecutar el mismo paso, y por eso cada acción debe ser idempotente: reservar con el mismo id_reserva no descuenta dos veces (02-03), cobrar con la misma clave_idempotencia no cobra dos veces (02-05). La saga hereda directamente el trabajo del Módulo 2.
• Los identificadores se deciden al inicio. id_reserva y clave_idempotencia se derivan del pedido_id y se guardan en datos en la primera transición, para que un reintento tras un reinicio use exactamente los mismos.
• Fallo permanente frente a transitorio. Un FalloPermanente (sin stock, tarjeta rechazada) dispara la compensación; un FalloTransitorio (deadline gRPC, 503 de la pasarela) se reintenta, y si es en un paso posterior al pivote se deja para un proceso periódico que llame a continuar sobre las sagas en curso (el índice sagas_en_curso existe para eso).
• Las compensaciones también son idempotentes (liberar de una reserva inexistente no hace nada) y se ejecutan en orden inverso, sin tocar los pasos que no llegaron a ejecutarse (en la saga 2, no hay nada que liberar).
• T1 y la saga en la misma transacción. En la versión real, pedidos_db.crear y el primer guardar de la saga van en una única transacción de km0_pedidos (y, si la saga se conduce por eventos, el primer comando va a la outbox en esa misma transacción). Así no puede existir un pedido pendiente sin saga ni una saga sin pedido.

En las tres sagas simuladas, el resultado es el que el monolito habría dado con ROLLBACK: Ana tiene su queso y su cobro; Marc no tiene ni queso ni vino, no se le ha cobrado nada, y el stock de vino ha vuelto a 12. La diferencia es que ha ocurrido en pasos separados, visibles desde fuera, y que los pedidos cancelados existen como registro.

En Kilómetro Cero, la saga del pedido tiene tres pasos hoy pero crecerá (asignación de repartidor, aviso al productor, cupones de campaña), y el equipo de soporte necesita saber en qué estado está cada pedido; por eso la elección es la orquestación en pedidos. La coreografía se reserva para reacciones simples y estables, como que analitica consuma pedido.confirmado.

Una compensación es una nueva transacción de negocio con efectos propios, no un ROLLBACK: el reembolso aparece en el extracto de Marc, la reserva liberada genera un stock.actualizado que catalogo mostrará, el pedido cancelado se queda en el historial con su motivo. Algunas acciones no tienen compensación posible (un correo enviado, un repartidor que ya salió) y deben colocarse después del pivote. Y toda compensación debe ser idempotente y no puede fallar de forma permanente: si reembolsar devuelve un error definitivo, la saga queda en un estado que exige intervención humana, y hay que diseñar para ello (un estado COMPENSACION_FALLIDA con alerta, 07-01).

Las sagas renuncian a la I de ACID, y eso produce anomalías concretas entre T1 y T4:

Estas contramedidas (bloqueo semántico, lecturas pesimistas, reordenación, valores conmutativos, y "versión de archivo" para conservar el estado previo) las catalogó Chris Richardson a partir del artículo original de García-Molina, y la mayoría se reducen a una idea: hacer visible que el estado es provisional en lugar de fingir aislamiento.

Una variante de la saga que recupera algo de aislamiento es TCC (Try-Confirm/Cancel): cada paso se divide en try (reservar el recurso de forma provisional, sin consumirlo), confirm (consumirlo definitivamente) y cancel (liberar la reserva). El orquestador ejecuta todos los try, y solo si todos tienen éxito ejecuta los confirm; en caso contrario, los cancel. Es 2PC a nivel de negocio, sin bloqueos de base de datos: inventario con ReservarStock y ConfirmarReserva/LiberarReserva ya es, de hecho, un recurso TCC, y la pasarela de pago con pre-autorización y captura, también. El precio es que cada servicio tiene que implementar las tres operaciones y gestionar reservas que caducan (un try sin confirm ni cancel porque el orquestador murió), lo que hace de TCC la elección cuando los recursos son escasos y disputados (la última unidad, una plaza, un asiento) y de la saga simple la elección para todo lo demás.

• Usar 2PC entre microservicios "porque es lo que hace la base de datos". Acopla, bloquea ante la caída del coordinador y no cubre pasarelas ni brokers. Reserva 2PC para el interior de un sistema que lo controla todo.
• Sagas con pasos no idempotentes. Tras un reinicio, el orquestador reejecuta el último paso. Sin id_reserva, sin clave de idempotencia, el stock se descuenta dos veces y el cliente paga dos veces. Los identificadores de idempotencia se generan al iniciar la saga y se persisten con ella.
• Compensaciones que pueden fallar sin plan. Diseña el estado de "compensación fallida", con alerta y procedimiento manual, antes de que ocurra en producción.
• El pivote en el sitio equivocado. Si el paso que más falla (el cobro) va primero, se compensa poco; si va último, se compensa todo lo anterior. Ordena: compensables, después el pivote, después los reintentables.
• Fingir aislamiento. Mostrar el stock descontado por una saga en curso como definitivo, o contar pedidos pendientes como ventas, produce los errores de la tabla del apartado 10. Modela explícitamente los estados provisionales.
• Orquestador con lógica de negocio de otros servicios. El orquestador decide el orden y las compensaciones; no decide si hay stock ni si la tarjeta es válida. Si empieza a hacerlo, se ha convertido en un monolito distribuido.
• Sagas sin timeout. Una saga en STOCK_RESERVADO durante horas porque pagos no responde retiene stock que otros querrían comprar. Define un plazo máximo por paso y por saga, tras el cual se compensa.
• Consejo: guarda el historial de la saga. Cuando un cliente pregunte por qué se canceló su pedido, "cobrar falló: tarjeta rechazada por el emisor" en la fila de sagas vale más que cualquier log.
• Consejo: prueba el orquestador con dobles que fallen en cada paso, de forma permanente y transitoria, y tras un "reinicio" (llamar a continuar con el estado guardado). Es el tipo de prueba que en 07-06 automatizaremos con ingeniería del caos.

Con la simulación del apartado 8, modela una caída del orquestador justo después de que inventario reserve el vino de Lucía (P-2026-000126, 2 unidades de vino-crianza, tarjeta válida) pero antes de la transición a STOCK_RESERVADO. Hazlo con un InventarioSimulado cuya reservar lance una excepción SystemExit la primera vez, tras haber reservado. Después crea un nuevo OrquestadorSagaPedido con el mismo RepositorioMemoria, los mismos servicios simulados, y llama a continuar(saga.id). ¿Qué pasos se reejecutan? ¿Se descuenta el stock dos veces? ¿Qué cambiarías en la implementación para que iniciar devolviera el saga.id aunque el proceso muera a mitad?

Kilómetro Cero quiere añadir "asignar repartidor" (reparto.asignar(pedido_id, ciudad), compensación reparto.desasignar(pedido_id), puede fallar de forma permanente si no hay repartidores en la ciudad) entre el cobro y la confirmación. Describe qué hay que cambiar en la orquestación (apartado 8) y en la coreografía (apartado 7): qué ficheros, qué eventos nuevos, qué consumidores. ¿Es correcto colocarlo después del cobro? ¿Qué implicaría para Marc, cuya tarjeta sí es válida esta vez, un fallo permanente en ese paso?

Para cada operación, elige 2PC, saga coreografiada, saga orquestada o TCC, y justifica en dos o tres frases:

1. Trasladar 50 unidades de tomate-rosa entre las tablas stock de inv-bcn e inv-vlc (ambas son PostgreSQL del mismo servicio inventario, sin pasarelas externas).
2. Registrar una entrega: reparto marca el pedido entregado, pedidos cambia el estado, analitica actualiza el tiempo medio de entrega, y se envía un correo a Ana.
3. Reservar las últimas 3 botellas de vino-crianza para un pedido de Lucía y cobrarlas con una tarjeta que requiere autenticación reforzada (el cliente puede tardar minutos en confirmarla en la app del banco).

Solución 1:

La saga quedó persistida en INICIADA con paso_actual = 0, así que continuar reejecuta reservar_stock. Como InventarioSimulado.reservar es idempotente por id_reserva (res-P-2026-000126 ya está en reservas), no descuenta dos veces: el stock queda en 10, se cobra a Lucía y la saga llega a COMPLETADA. Si quitas la comprobación if id_reserva in self.reservas, verás el stock en 8: es exactamente el fallo que la idempotencia de 02-03 evita. Sobre iniciar: en la implementación real no devuelve nada a nadie si el proceso muere; lo importante es que la saga esté en la tabla, y un proceso periódico (SELECT id FROM sagas WHERE estado NOT IN ('COMPLETADA','CANCELADA') AND actualizada_en < now() - interval '1 minute') llame a continuar sobre las sagas huérfanas. Además, iniciar debería crear el pedido y la saga en una sola transacción y responder al cliente "pedido recibido, pendiente" antes de ejecutar los pasos, que pueden tardar.

Solución 2:

Orquestación: un solo cambio en saga_pedido.py: insertar un Paso("asignar_repartidor", "REPARTIDOR_ASIGNADO", accion=reparto.asignar(...), compensacion=reparto.desasignar(...)) en la lista self.pasos entre cobrar y confirmar_pedido, añadir ciudad a datos, y admitir el nuevo estado en la tabla sagas. Los servicios inventario y pagos no cambian. Coreografía: reparto necesita un consumidor nuevo de pago.confirmado que publique repartidor.asignado o reparto.imposible; pedidos deja de confirmar al recibir pago.confirmado y pasa a hacerlo con repartidor.asignado; pago.rechazado sigue igual, pero reparto.imposible debe disparar dos compensaciones: pagos debe consumirlo y reembolsar (nuevo consumidor) y luego inventario debe liberar al recibir pago.reembolsado (evento nuevo y consumidor nuevo). Tres servicios tocados, dos eventos nuevos, y la cadena de compensación se alarga.

¿Después del cobro? Si "asignar repartidor" puede fallar de forma permanente, colocarlo después del pivote (cobro) obliga a reembolsar, que es la compensación más visible y molesta para el cliente (Marc vería un cargo y un abono en su extracto). Sería mejor colocarlo antes del cobro (reservar repartidor es compensable y barato de deshacer), convirtiendo el cobro de nuevo en el último paso compensable-o-pivote. Regla general: los pasos que pueden fallar permanentemente van antes del pivote.

Solución 3:

1. 2PC (o, mejor, una única transacción): ambas tablas pertenecen al mismo servicio, inventario, así que no hay acoplamiento indebido; si están en la misma base de datos lógica no hace falta nada distribuido, y si son dos instancias PostgreSQL, PREPARE TRANSACTION entre ellas, coordinado por inventario, es adecuado: participantes homogéneos, sin pasarelas, transacción corta y el propio servicio puede resolver transacciones preparadas huérfanas al arrancar (consultando pg_prepared_xacts). Una saga sería sobreingeniería.
2. Saga coreografiada: reparto publica pedido.entregado en la misma transacción que su cambio de estado (outbox), y pedidos, analitica y el servicio de notificaciones lo consumen de forma independiente e idempotente. No hay compensación posible ni necesaria (una entrega no se "des-entrega"), no hay pivote, y ningún paso depende del resultado de otro: es la reacción simple y estable para la que la coreografía encaja.
3. TCC: las tres últimas botellas son un recurso escaso y disputado, y el cobro puede tardar minutos por la autenticación reforzada. inventario hace try (reserva provisional con caducidad, por ejemplo 15 minutos), pagos hace try (pre-autorización pendiente de confirmación del cliente); cuando el banco confirma, el orquestador ejecuta confirm en ambos (consumir la reserva, capturar el cobro); si Lucía no confirma a tiempo, cancel en ambos. Durante la espera, el catálogo muestra las botellas como reservadas, no vendidas ni disponibles: el estado provisional explícito del apartado 10. Una saga simple con cobro inmediato no puede esperar minutos con el stock descontado sin aparecer como vendido, y 2PC no puede incluir a la pasarela.

La transacción del monolito, con su COMMIT que lo confirmaba todo o nada, no existe cuando el pedido cruza pedidos, inventario y pagos, y esta lección ha mostrado las dos maneras de vivir sin ella. El commit en dos fases conserva la atomicidad con un coordinador que recoge votos en la fase de prepare y difunde la decisión en la de commit; PostgreSQL lo soporta con PREPARE TRANSACTION, y lo hemos visto bloquear filas indefinidamente cuando el coordinador muere con los participantes preparados. Ese bloqueo, junto con el acoplamiento, la latencia y la imposibilidad de incluir pasarelas y brokers, es la razón por la que los microservicios evitan 2PC (3PC no ayuda sin red síncrona; el remedio real es un coordinador replicado por consenso, que solo las bases de datos distribuidas se permiten). La saga sustituye la atomicidad por una secuencia de transacciones locales con compensaciones, ordenadas en compensables, pivote y reintentables. La hemos implementado como coreografía, con consumidores idempotentes y outbox encadenando pedido.creado, stock.reservado, pago.rechazado y stock.liberado, y como orquestación en saga_pedido.py, con la tabla sagas de km0_pedidos persistiendo cada transición y un continuar reentrante que retoma la saga tras un reinicio gracias a la idempotencia de id_reserva y de la clave de cobro heredadas del Módulo 2; la simulación ha compensado la reserva de Marc cuando pagos lo rechazó y ha dejado el stock intacto. La tabla del apartado 9 justifica la elección de la orquestación para el pedido de Kilómetro Cero, y el apartado 10 ha puesto nombre a lo que la saga pierde, el aislamiento, con contramedidas (bloqueo semántico, estados provisionales, lecturas pesimistas, valores conmutativos) y con TCC como variante para recursos disputados.

Con esta lección se cierra el Módulo 3. Sabemos ya decir con precisión qué garantiza un almacén replicado (modelos de consistencia), qué hay que sacrificar cuando la red se parte y qué cuesta la consistencia cuando no (CAP y PACELC), cómo un grupo de nodos elige líder y acuerda valores (Paxos, Raft, etcd), cómo se copian los datos entre nodos y con qué anomalías (líder-seguidor, multilíder, quórums), y cómo una operación de negocio atraviesa varios servicios sin una transacción global (2PC y sagas). Todo ello trata los datos como si ya estuvieran en algún sitio. El Módulo 4 se ocupa de ese sitio: dónde y cómo se guardan físicamente los pedidos, las fotos de los productos y los eventos que ya sabemos replicar y coordinar, cuando son demasiados para un solo nodo. Empieza por la pregunta previa a cualquier réplica: cómo repartir datos distintos entre muchos nodos, con el particionado y el hashing consistente.