Al separar las bases de datos hemos perdido, a sabiendas, la pieza que hacía cómodo el monolito: la transacción única de crearPedido, ese BEGIN ... COMMIT que reservaba stock, creaba el pedido, registraba el pago y, si algo fallaba, lo deshacía todo con un ROLLBACK. Ahora la reserva vive en la base de datos de Inventario, el pago en la de Pagos y el pedido en la de Pedidos, y no existe ningún ROLLBACK que abarque las tres. El esquema de 02-04 dejó las pistas: estados STOCK_RESERVADO y PAGADO en pedidos, expira_en en reservas, un motivo_cancelacion. Esta lección explica qué sustituye a esa transacción.

Veremos por qué no hay transacciones ACID entre servicios (y por qué el two-phase commit se descarta), qué significa en la práctica el teorema CAP y la consistencia eventual, el patrón saga en sus dos variantes (coreografía y orquestación), el diseño completo de la saga "crear pedido" de TechCorp con los eventos del curso, sus transacciones compensatorias y la máquina de estados del pedido, la decisión razonada de empezar por coreografía, el patrón outbox transaccional que garantiza que un evento se publica si y solo si el cambio se guardó, la idempotencia de los consumidores, y las dos ideas que suelen acompañar a las sagas: CQRS (modelos separados de escritura y lectura) y event sourcing (guardar eventos en lugar de estado), con la decisión de TechCorp sobre cada una. Todo a nivel de diseño: cómo se configura RabbitMQ y cómo se publica un evento desde Node.js se ve en 03-02 y 04-04.

1. Por qué no hay transacciones ACID entre servicios
2. El teorema CAP y la consistencia eventual, en términos prácticos
3. El patrón saga: coreografía frente a orquestación
4. La saga "crear pedido" de TechCorp
5. La máquina de estados del pedido
6. La decisión de TechCorp: coreografía para empezar
7. El patrón outbox transaccional
8. Idempotencia de los consumidores y claves de idempotencia
9. CQRS: separar el modelo de escritura del de lectura
10. Event sourcing: guardar los hechos en lugar del estado

Una transacción ACID (atómica, consistente, aislada, duradera) es una promesa que hace un motor de base de datos sobre sus datos. En cuanto los datos están en dos motores (PostgreSQL de Pedidos y PostgreSQL de Inventario, o PostgreSQL y MongoDB), ninguno de los dos puede prometer nada sobre el otro.

Existe un protocolo para coordinar varias bases de datos en una sola transacción: el two-phase commit (2PC, "confirmación en dos fases"). Un coordinador pregunta a todos los participantes "¿podéis confirmar?" (fase 1: prepare); si todos dicen sí, ordena "confirmad" (fase 2: commit); si alguno dice no, ordena "abortad". Suena perfecto, y en microservicios se descarta casi siempre por estas razones:

La conclusión de la industria, y de TechCorp: entre servicios no hay atomicidad; hay secuencias de transacciones locales, cada una atómica dentro de su servicio, coordinadas por mensajes, y con acciones de compensación para deshacer lo hecho cuando un paso posterior falla. Eso es una saga.

El teorema CAP (Brewer) dice que un sistema distribuido, ante una partición de red (P: dos partes no pueden comunicarse), debe elegir entre consistencia (C: todos ven el mismo dato en el mismo instante) y disponibilidad (A: todos reciben respuesta). Como las particiones ocurren (falacia 1 de 01-02: la red no es fiable), la elección real es "cuando la red falle, ¿prefiero responder con datos posiblemente desactualizados o prefiero no responder?".

Para el flujo de pedido de TechCorp, la respuesta es matizada:

• Dentro de cada servicio, consistencia fuerte: servicio-inventario no reservará jamás más de lo que hay (reservado <= cantidad es una restricción de su base de datos).
• Entre servicios, consistencia eventual: durante unos segundos, el pedido está PENDIENTE en Pedidos mientras Inventario ya ha reservado; la web puede mostrar "procesando" y el cliente recibirá el correo cuando todo converja. Es aceptable porque el negocio lo tolera: nadie necesita saber en el mismo milisegundo que el stock y el pedido están de acuerdo.

"Eventual" significa "garantizado, pero no instantáneo": si dejan de llegar cambios, todas las copias acaban coincidiendo. No significa "a veces": un sistema que pierde eventos no es eventualmente consistente, es incorrecto. Los apartados 7 y 8 (outbox e idempotencia) son precisamente lo que convierte "eventual" en "garantizado".

Lo que cambia para el equipo, dicho sin teoría: entre que se crea el pedido y se confirma pueden pasar segundos, y en ese intervalo el sistema está en un estado intermedio legítimo que hay que modelar, mostrar y saber deshacer. En el monolito ese intervalo no existía para nadie externo; ahora forma parte del diseño.

Una saga es una secuencia de transacciones locales T1, T2, ..., Tn, cada una en un servicio distinto, donde cada Ti publica un mensaje que dispara Ti+1. Si Ti falla, se ejecutan las transacciones compensatorias Ci-1, ..., C1 que deshacen semánticamente lo anterior. "Semánticamente" es importante: no es un ROLLBACK (el cobro ya se hizo), es una acción de negocio inversa (un reembolso).

Hay dos formas de coordinar la secuencia:

Ninguna es "la buena". La regla práctica: coreografía por defecto para flujos simples; orquestación cuando el flujo crece o cuando la visibilidad se vuelve un problema.

Diseñamos la saga con los eventos del curso. Los cinco eventos principales ya son conocidos desde 01-05; el event storming de 02-02 destapó los de fallo y compensación, que ahora nombramos con la misma convención <contexto>.<hecho>:

Los pasos, en el camino feliz y en los dos caminos de fallo:

Observaciones de diseño, una por una:

• La respuesta al cliente es 202 Accepted con estado PENDIENTE, no 201 con CONFIRMADO como hacía el monolito. El pedido existe, pero no está completo; el cliente consulta GET /pedidos/ped-88213 (o recibe una notificación) para ver la confirmación. Es el estado intermedio legítimo del apartado 2, hecho visible en el contrato. (Comparado con la respuesta de 01-01, donde POST /pedidos devolvía 201 con PENDIENTE: ambas son válidas; el curso adopta 202 a partir de aquí para subrayar que el procesamiento continúa. El diseño concreto de la API se cierra en 03-01.)
• T1 conserva las validaciones síncronas con Clientes y Catálogo (existencia del cliente, precios actuales): sin ellas no hay pedido que crear. Lo que sale de la petición HTTP es todo lo demás.
• Pagos reacciona a stock.reservado, no a pedido.creado. Cobrar antes de saber si hay stock obligaría a reembolsar con frecuencia; reservar primero y cobrar después minimiza compensaciones caras. El orden de la saga se elige poniendo primero los pasos más probables de fallar y más baratos de compensar.
• pedido.confirmado tiene dos consumidores: Notificaciones (correo) e Inventario (convertir la reserva en descuento definitivo de stock). En el monolito ese descuento estaba dentro de la transacción; ahora es la última transacción local de Inventario.
• Las compensaciones son eventos de negocio, no comandos "deshaz": Inventario libera stock porque el pedido se canceló, y publica stock.liberado; Pagos reembolsaría (pago.reembolsado) solo si el pedido se cancela después de pago.confirmado, algo que en este flujo básico ocurre si Pedidos, ya PAGADO, no pudiera confirmar (por ejemplo, por una regla antifraude posterior) o si el cliente cancela en el plazo permitido. Es una rama que el equipo diseña aunque hoy sea rara.
• El evento lleva lo que el consumidor necesita. pedido.creado incluye líneas (con productoId, cantidad, precioUnitario, nombre), total, email, nombre del cliente y direccionEnvio; así Inventario reserva sin consultar a nadie, Pagos cobra sin consultar a nadie y Notificaciones escribe el correo sin consultar a nadie (patrón conformist de 02-03). Ejemplo:

El eventoId único y la version no son adorno: el primero es la base de la idempotencia (apartado 8) y la segunda, del versionado de contratos (03-06). Todos los eventos del curso llevan este sobre (eventoId, tipo, version, ocurridoEn) más su carga.

La saga se ve, desde servicio-pedidos, como una máquina de estados del agregado Pedido. Definirla explícitamente es lo que evita que un evento tardío o duplicado deje un pedido en un estado absurdo (por ejemplo, un pago.confirmado que llega para un pedido ya CANCELADO).

PAGADO parece redundante (¿por qué no pasar de STOCK_RESERVADO a CONFIRMADO directamente?). Se mantiene separado por dos razones: permite distinguir "he registrado el pago pero aún no he publicado la confirmación" ante una caída entre ambas escrituras, y deja hueco para reglas de confirmación futuras (antifraude, validación de dirección) sin cambiar la saga.

El plazo agotado merece atención: si Pagos está caído durante media hora, los pedidos quedan en STOCK_RESERVADO con stock apartado que nadie compra. servicio-pedidos incluye un vigilante (una tarea periódica) que cancela por TIMEOUT_PAGO los pedidos que lleven más de N minutos en ese estado; y, como red de seguridad independiente, reservas.expira_en permite a Inventario liberar reservas huérfanas aunque Pedidos no lo pida. Dos mecanismos, cada uno en su contexto, para el mismo riesgo.

Esqueleto de la máquina de estados y de un consumidor de compensación (ilustrativo: sin acceso a base de datos real ni a RabbitMQ; la implementación llega en el módulo 4):

Fíjate en que ambos esqueletos empiezan comprobando el estado y salen sin hacer nada si el evento no procede: es la mitad de la idempotencia; la otra mitad está en el apartado 8.

Luis y su equipo eligen coreografía para la saga de pedido, por estas razones:

• El flujo es corto y lineal: cuatro transacciones, dos puntos de fallo, dos compensaciones.
• Encaja con el mapa de contextos de 02-03: Pedidos–Inventario son partnership por eventos, Pagos y Notificaciones consumen el lenguaje publicado. Nadie tiene que "mandar" sobre nadie.
• Refuerza la autonomía: añadir un consumidor (por ejemplo, un futuro servicio-promociones que escuche pedido.confirmado para consumir un cupón) no toca a nadie.
• El equipo aprende con lo más sencillo antes de añadir una pieza (el orquestador) que hay que operar y monitorizar.

Y fijan por escrito cuándo pasarán a orquestación, para no descubrirlo en un incidente:

Si llega el momento, el orquestador vivirá dentro de servicio-pedidos (es el dueño del ciclo de vida del pedido) y enviará comandos a Inventario y Pagos; los eventos públicos (pedido.confirmado, pedido.cancelado) se mantendrán para Notificaciones y para quien venga después. La máquina de estados del apartado 5 es la misma en ambos casos: por eso se define ya.

Hay un fallo sutil que rompería toda la saga si no se trata. servicio-pedidos debe hacer dos cosas al crear un pedido: guardar la fila en su PostgreSQL y publicar pedido.creado en RabbitMQ. Son dos sistemas distintos, luego no hay transacción que abarque ambos, y las dos ordenaciones fallan:

• Guardar y luego publicar: si el proceso cae entre ambas, el pedido existe pero nadie lo sabe: se queda PENDIENTE para siempre.
• Publicar y luego guardar: si falla el guardado, Inventario reserva stock para un pedido que no existe.

Es el mismo problema del dual write de 02-04, en versión mensajería. La solución es el outbox transaccional ("bandeja de salida"):

1. En la misma transacción local en la que se guarda el pedido, se inserta el evento en una tabla outbox de la misma base de datos. O se guardan los dos, o ninguno: eso sí lo garantiza PostgreSQL.
2. Un componente aparte (el relay) lee la tabla outbox, publica los eventos pendientes en el broker y los marca como publicados. Si el relay cae, al volver sigue donde estaba: ningún evento se pierde.
3. Como el relay puede publicar un evento dos veces (por ejemplo, publica y cae antes de marcar), la entrega es al menos una vez, y los consumidores deben ser idempotentes (apartado 8).

Y el uso, en pseudocódigo, desde el repositorio de Pedidos (es el guardarConEventos que apareció en el apartado 5):

Dos precisiones. Primera: el relay puede ser una tarea periódica del propio servicio (polling de la tabla cada pocos cientos de milisegundos) o una herramienta de captura de cambios (CDC); TechCorp empieza con polling, que es suficiente para 3.000 pedidos/día, y el detalle de implementación se ve en 04-04. Segunda: la tabla outbox es también un registro de auditoría gratuito de todo lo que el servicio ha comunicado al exterior, algo que resultará valioso en 06-03.

Con entrega "al menos una vez", todo consumidor recibirá algún evento repetido tarde o temprano (reintento del relay, reentrega del broker tras un fallo de confirmación, redespliegue en mitad de un procesamiento). Idempotente significa que procesar el mismo evento dos veces produce el mismo resultado que procesarlo una: Inventario no reserva dos veces, Pagos no cobra dos veces, Notificaciones no envía dos correos.

Hay dos mecanismos complementarios, y el diseño de TechCorp usa ambos:

a) Idempotencia natural por el modelo. Diseñar las escrituras de forma que la repetición no cambie nada:

• reservas.pedido_id UNIQUE: un segundo pedido.creado para el mismo pedido choca con la restricción y el consumidor lo trata como "ya hecho".
• pagos.pedido_id UNIQUE: un segundo stock.reservado no produce un segundo cobro.
• La máquina de estados: un segundo pago.confirmado sobre un pedido ya PAGADO/CONFIRMADO no tiene transición y se ignora.

b) Registro de eventos procesados. Para consumidores cuyo efecto no es una fila única (enviar un correo, llamar a la pasarela), se guarda el eventoId en la misma transacción que el efecto:

Cuando el efecto es externo (llamar a la pasarela de pago) no se puede meter en la transacción; en ese caso se registra antes un intento con estado "en curso" y se usa la clave de idempotencia de la propia pasarela (todas las pasarelas serias aceptan una, precisamente por esto): pasarela.cobrar({ importe, claveIdempotencia: pedidoId }). Si se repite la llamada, la pasarela devuelve el mismo resultado sin cobrar de nuevo.

c) La clave de idempotencia en la API. El sexto problema de crearPedido en 01-05 era el "doble clic": dos POST /pedidos iguales, dos pedidos, dos cobros. La solución de diseño es que el cliente envíe una cabecera Idempotency-Key (un UUID generado por el navegador para ese intento de compra) y que servicio-pedidos guarde, en su transacción de T1, la pareja clave → pedidoId y respuesta; ante una repetición con la misma clave, devuelve la misma respuesta sin crear nada. La forma exacta de la cabecera y de la respuesta se cierra en 03-01; el diseño de datos es una tabla más en pedidos:

Con outbox (los eventos salen seguro) e idempotencia (los eventos repetidos no hacen daño), la consistencia eventual pasa de "esperemos que llegue" a "garantizado".

CQRS (Command Query Responsibility Segregation) es la idea de usar modelos distintos para escribir y para leer. En 02-04 apareció como "vista materializada" y como respuesta al panel de administración con filtros cruzados; ahora tiene nombre y mecánica.

• El modelo de escritura es el agregado Pedido con sus invariantes y su máquina de estados, en las tablas pedidos y lineas_pedido. Está optimizado para decidir (¿puedo confirmar?, ¿puedo cancelar?).
• El modelo de lectura es una o varias tablas desnormalizadas, construidas por un proyector que consume eventos, y optimizadas para mostrar: sin JOIN, con exactamente las columnas que necesita cada pantalla.

Para "pedidos con nombre de cliente y de producto" del panel de administración:

Dónde vive: TechCorp empieza con la vista dentro de servicio-pedidos (misma base de datos, tabla distinta, alimentada por sus propios eventos y por cliente.actualizado). Es CQRS "ligero": no hace falta un servicio de consultas separado hasta que el volumen o los consumidores lo justifiquen. Si el día de mañana el panel necesita cruzar datos de cinco contextos, la vista se mueve a un servicio de consultas o al almacén analítico de 02-04.

Cuándo compensa CQRS y cuándo no:

CQRS trae consistencia eventual entre escritura y lectura: un pedido recién creado tarda milisegundos o segundos en aparecer en la vista. Para el panel de administración es irrelevante; para "acabo de crear el pedido y quiero verlo" hay que leer del modelo de escritura o devolver la representación en la respuesta del comando.

Event sourcing lleva la idea un paso más allá: no se guarda el estado actual del agregado, sino la secuencia de eventos que lo produjeron, y el estado se reconstruye reproduciéndolos. La tabla pedidos con su columna estado desaparecería; en su lugar habría un event store:

Decisión de TechCorp: no, por ahora. Justificación:

1. El estado del pedido es sencillo (cinco estados, dos ramas) y el modelo relacional de 02-04 lo representa sin esfuerzo.
2. Las necesidades de auditoría (saber por qué se canceló un pedido, cuándo se cobró) se cubren con motivo_cancelacion, con la tabla outbox (que ya conserva todo lo comunicado) y con una tabla historial_estados_pedido si hiciera falta, a una fracción del coste.
3. El equipo está aprendiendo a la vez sagas, outbox, idempotencia, Docker, Kubernetes y observabilidad. Añadir event sourcing multiplicaría el riesgo de la migración sin resolver ninguno de los cinco problemas de 01-05.
4. Se puede adoptar más adelante en un solo contexto (Pedidos o Pagos, si un requisito regulatorio lo exige) sin tocar a los demás, gracias precisamente a que cada servicio es dueño de su almacenamiento.

Es una decisión típica de arquitectura: no se descarta la técnica, se descarta ahora y se deja escrita la señal que la reabriría.

• Intentar recuperar el 2PC "con un poco de código": bloquear stock mientras se llama a Pagos por HTTP y esperar la respuesta. Es la transacción de crearPedido con más latencia y más fallos. Si un paso puede fallar, diseña su compensación.
• Compensaciones incompletas. Cada paso que modifica algo necesita su inversa diseñada antes de desplegar: reservar ↔ liberar, cobrar ↔ reembolsar, confirmar ↔ (no hay: por eso es el último).
• Publicar el evento fuera de la transacción. Sin outbox, se pierden eventos, y perder un pedido.creado es un pedido zombi. La outbox no es opcional.
• Suponer que un evento llega una sola vez y en orden. Llegará repetido y, a veces, desordenado (un pago.confirmado puede alcanzar a Pedidos antes que el stock.reservado si el consumidor iba lento). La máquina de estados y el registro de eventos procesados protegen de ambas cosas.
• Orquestador que sabe demasiado. Si algún día se pasa a orquestación, el orquestador manda comandos y espera respuestas; no calcula stock ni decide cobros. Eso es de cada contexto.
• CQRS y event sourcing "porque son lo moderno". CQRS solo donde una consulta lo pida; event sourcing solo donde el histórico sea el negocio.
• Consejo: dibuja siempre la saga como diagrama de secuencia y como máquina de estados. El primero enseña el camino feliz; la segunda es la que te obliga a pensar en los eventos tardíos, duplicados y fuera de orden.

Por un reinicio del consumidor, servicio-pedidos recibe pago.confirmado de ped-88213 antes que stock.reservado (ambos existen y son válidos). Con la máquina de estados del apartado 5: ¿qué ocurre con cada evento?, ¿queda el pedido en un estado correcto al final?, ¿qué habría que cambiar en el diseño si esa situación fuese frecuente?

TechCorp permitirá que el cliente cancele un pedido CONFIRMADO durante los 30 minutos siguientes. Diseña la ampliación de la saga: qué transición se añade a la máquina de estados, qué evento publica Pedidos, qué hace cada consumidor (Inventario, Pagos, Notificaciones), y qué garantiza que un doble clic en "cancelar" no reembolsa dos veces.

servicio-catalogo publica producto.actualizado cada vez que un operador guarda una ficha en MongoDB. Un compañero propone publicar directamente en RabbitMQ después de guardar, "porque MongoDB no es PostgreSQL y no tenemos outbox". Explica qué puede fallar, cómo aplicarías el patrón outbox con MongoDB (pista: una colección outbox y transacciones de MongoDB, o el propio documento) y qué consumidor de TechCorp sufriría si se perdiera un producto.actualizado.

Ejercicio 1

El pedido está en PENDIENTE. Llega pago.confirmado: en PENDIENTE no hay transición para ese evento → se ignora y se registra un aviso (transicion_ignorada). Luego llega stock.reservado: PENDIENTE → STOCK_RESERVADO, correcto. Pero el pago.confirmado ya se descartó, así que el pedido se quedaría en STOCK_RESERVADO hasta que el vigilante lo cancele por TIMEOUT_PAGO, y Pagos habría cobrado: acabaría en CANCELADO con un pago.confirmado "huérfano" que exige reembolso. Es correcto en el sentido de que no hay estado imposible, pero es un mal resultado de negocio. Si fuera frecuente, hay dos mejoras: (a) en lugar de descartar el evento no aplicable, aparcarlo (guardarlo como "pendiente de aplicar" y reintentarlo cuando cambie el estado, o pedir al broker que lo reentregue más tarde); (b) hacer que Pagos incluya en pago.confirmado la reservaId, de modo que Pedidos pueda aceptar PENDIENTE → PAGADO sabiendo que la reserva existe. En la práctica el desorden es raro porque pago.confirmado es causalmente posterior a stock.reservado, y (a) basta.

Ejercicio 2

• Transición nueva: CONFIRMADO → CANCELADO con evento de entrada cancelacion.solicitada (comando del cliente vía POST /pedidos/{id}/cancelacion), permitida solo si NOW() - confirmado_en <= 30 min y el pedido no ha salido de almacén (regla del contexto Pedidos; en un diseño más completo, "enviado" sería otro estado que bloquearía la cancelación).
• Pedidos publica pedido.cancelado con motivo: 'CANCELADO_POR_CLIENTE' y, en la carga, pagoId o pedidoId para que Pagos localice el cobro.
• Inventario: la reserva ya está CONSUMIDA (el stock se descontó al confirmar); su compensación es reponer cantidad (cantidad += n) y publicar stock.liberado (o un stock.repuesto, si se quiere distinguir).
• Pagos: busca el pago CAPTURADO del pedido; si existe, reembolsa en la pasarela con clave de idempotencia reembolso-<pedidoId> y publica pago.reembolsado; si no existe cobro, no hace nada.
• Notificaciones: correo "pedido cancelado, reembolso en curso".
• Doble clic: la segunda POST .../cancelacion encuentra el pedido ya CANCELADO (sin transición → 409 o respuesta idempotente); aunque llegase un segundo pedido.cancelado, Pagos lo detecta por eventos_procesados y por el estado REEMBOLSADO de su fila; y la pasarela lo detiene por la clave de idempotencia. Tres capas.

Ejercicio 3

Puede fallar exactamente lo mismo que en PostgreSQL: el proceso cae entre guardar el documento y publicar (evento perdido: la réplica de precios de quien lo consuma queda desactualizada) o publica y luego falla el guardado (evento fantasma). El patrón es el mismo con MongoDB: (a) usar una transacción multi-documento de MongoDB (disponible en replica sets) para escribir el documento de productos y un documento en la colección outbox atómicamente, con un relay que lea outbox y publique; o (b) escribir los eventos pendientes dentro del propio documento de producto (eventosPendientes: [...]) en la misma operación de escritura, y que el relay los extraiga y los vacíe (variante "outbox embebida", útil sin transacciones); o (c) usar change streams de MongoDB como mecanismo de CDC. Quién sufriría: cualquier consumidor que mantenga una réplica de datos de catálogo (por ejemplo, la vista materializada del panel si mostrase nombres actualizados, o el almacén analítico de 02-04 para categorías). servicio-pedidos no sufre al crear pedidos porque consulta el precio por composición síncrona; ese fue justamente el motivo de esa decisión en 02-04.

Hemos sustituido la transacción única de crearPedido por un diseño distribuido completo. Sabemos por qué no hay ACID entre servicios y por qué el 2PC se descarta (bloqueos, coordinador único, sistemas externos), qué significa en la práctica la consistencia eventual (estados intermedios legítimos, garantizados pero no instantáneos), y hemos diseñado la saga "crear pedido" de TechCorp por coreografía: pedido.creado → stock.reservado → pago.confirmado → pedido.confirmado, con los eventos de fallo stock.rechazado y pago.rechazado, el evento pedido.cancelado (con motivo SIN_STOCK, PAGO_RECHAZADO o TIMEOUT_PAGO) y las compensaciones stock.liberado y pago.reembolsado. La máquina de estados PENDIENTE → STOCK_RESERVADO → PAGADO → CONFIRMADO / CANCELADO gobierna qué evento se acepta y cuál se ignora; el outbox transaccional garantiza que un evento sale si y solo si el cambio se guardó; la idempotencia (restricciones UNIQUE, tabla eventos_procesados, cabecera Idempotency-Key, claves de la pasarela) hace inofensivas las repeticiones. Con CQRS hemos añadido la vista vista_pedidos_admin alimentada por un proyector, y hemos decidido que event sourcing no compensa hoy para TechCorp, dejando escritas las señales que reabrirían la decisión (igual que las que llevarían de coreografía a orquestación).

Con esto termina el módulo de diseño: tenemos principios, un plan de descomposición con orden de extracción, seis bounded contexts con su mapa de relaciones, una base de datos por servicio con su esquema, y una saga con outbox e idempotencia. Lo que aún no hemos decidido es cómo hablan exactamente los servicios: la forma de las APIs REST de cada uno (POST /pedidos con su 202, GET /productos?ids=, POST /reservas), cómo se publican y consumen de verdad los eventos en RabbitMQ, cuándo conviene gRPC o GraphQL, qué hace el API Gateway del puerto 8080, cómo se encuentran los servicios entre sí y cómo se versionan los contratos sin romper a nadie. Ese es el módulo 3, y empieza por las APIs RESTful.