Ya sabemos qué contextos hay en TechCorp y qué guarda cada uno de "producto" y de "cliente". Falta la decisión que más cuesta tomar y la que más consecuencias tiene: separar físicamente los datos. Mientras los seis servicios sigan leyendo y escribiendo la única base de datos techcorp, no habrá autonomía real: cualquier cambio de esquema será una negociación entre equipos, cualquier consulta pesada del catálogo bloqueará una migración de pedidos y el "microservicio" será un monolito distribuido con más latencia.

Esta lección desarrolla el patrón database-per-service: por qué la base de datos compartida es el antipatrón principal, qué grados de aislamiento existen (esquemas separados, instancias separadas, tecnologías distintas), cómo se rompen las claves foráneas cruzadas del esquema de 01-05, qué se hace con las consultas que hoy son un JOIN, quién es dueño de cada dato, cómo se migran los datos sin parar la tienda y, como resultado, qué esquema concreto tendrá cada servicio de TechCorp (SQL de servicio-pedidos y servicio-inventario, documento del catálogo en MongoDB). Cerramos adelantando la cuestión del reporting. La consistencia entre esas bases de datos separadas (sagas, CQRS, event sourcing) es el tema de la lección siguiente.

1. El patrón database-per-service y el antipatrón de la base de datos compartida
2. Grados de aislamiento: del esquema separado a la persistencia políglota
3. Romper las claves foráneas cruzadas
4. Las consultas que antes eran un JOIN
5. Propiedad y ciclo de vida de los datos
6. Migrar los datos sin parar la tienda
7. El esquema resultante de cada servicio de TechCorp
8. Implicaciones para reporting y analítica

El patrón se enuncia en una línea: cada servicio es el único que accede a su almacenamiento; los demás solo llegan a esos datos a través de su API o de sus eventos. "Almacenamiento" incluye tablas, colecciones, índices, colas privadas y ficheros. Es la materialización del principio "datos descentralizados" de 02-01 y del "contrato como única puerta".

Por qué la base de datos compartida es el antipatrón principal (y no uno más):

En resumen: con la base de datos compartida se cumplen todos los acoplamientos de 02-01 (de datos, de despliegue, temporal) a la vez. Es por eso que la lección 01-01 lo definió como "lo que un microservicio no es".

Lo que se paga a cambio, y que el resto de la lección gestiona: se pierden los JOIN entre contextos, se pierden las claves foráneas cruzadas y se pierde la transacción única.

Separar los datos no es todo o nada. Hay una escalera, y subir peldaño a peldaño es una estrategia de migración legítima:

El peldaño 1 es barato y ya elimina el problema más grave (el acoplamiento de esquema). Cómo se hace en PostgreSQL:

Con esto, la línea SELECT ... FROM clientes de crearPedido falla en tiempo de ejecución si el servicio de pedidos usa svc_pedidos. Es una forma eficaz de que la regla "no toques tablas ajenas" deje de ser una convención y pase a ser una restricción técnica.

La persistencia políglota no es "usar tecnologías variadas porque se puede"; es elegir por el modelo de datos y el patrón de acceso:

Y una regla de prudencia que Marta impone: como máximo dos tecnologías de base de datos en el sistema. Cada tecnología nueva es copia de seguridad, monitorización, conocimiento y guardias distintas. MongoDB se justifica por el problema 5 de 01-05; una tercera tecnología necesitaría un problema igual de concreto.

Recuperemos el esquema de 01-05 y asignemos dueño a cada tabla, marcando las claves foráneas que cruzan fronteras:

Una clave foránea cruzada es incompatible con database-per-service por definición: PostgreSQL no puede comprobar que pedidos.cliente_id existe en una tabla que está en otra base de datos (o en otro servidor). Así que se sustituye por una referencia por identificador: una columna con el id del otro contexto, sin restricción de integridad en la base de datos.

Qué se pierde y cómo se compensa:

El último punto merece énfasis: en cuanto un identificador viaja entre servicios, deja de poder ser un entero autoincremental local. servicio-pedidos no puede generar pedido_id = 42 y servicio-pagos almacenar 42, porque si un día se restaura una copia o se particiona la tabla, el 42 deja de ser único. TechCorp adopta identificadores de texto generados por el servicio dueño (en el curso, con prefijo legible: ped-, c-, p-, pag-, res-; en producción, UUID o ULID con ese prefijo).

El caso paradigmático de TechCorp: el panel de administración muestra "pedidos del día con nombre del cliente y nombre de los productos". Hoy:

Con clientes en una base de datos, productos en MongoDB y pedidos en otra, este JOIN no existe. Hay tres alternativas, y elegir bien depende de la frecuencia, la tolerancia a datos ligeramente desactualizados y de quién es el dato:

En código, la composición de APIs se parece a esto (esqueleto; el cliente HTTP real, con timeouts y reintentos, se construye en 04-04):

Y la réplica local, en el esquema de servicio-pedidos:

Decisión de TechCorp para el flujo de pedido:

• Al crear un pedido, servicio-pedidos consulta a Catálogo (precio y nombre actuales) y a Clientes (existencia, email, dirección) por composición: son dos llamadas, el dato tiene que ser el actual y el pedido no puede crearse sin ellas. Es el acoplamiento temporal deliberado que señalamos en 02-02.
• Para listar pedidos con nombre de cliente, servicio-pedidos usa su réplica clientes_ref.
• Para el panel de administración con filtros cruzados, una vista materializada alimentada por eventos (02-05).

Fíjate en que las copias congeladas de lineas_pedido (nombre_producto, precio_unitario) no son una réplica: no se actualizan cuando el catálogo cambia. Son datos del pedido. clientes_ref sí es una réplica: si el cliente cambia de nombre, debe reflejarlo.

Con los datos separados hace falta responder, dato por dato, tres preguntas: quién escribe, quién lee y quién decide cuándo desaparece.

Dos casos que la tabla resuelve y que en el monolito ni se planteaban:

• La réplica tiene dos "escritores" aparentes: la API de Pedidos y el consumidor de eventos de Pedidos. Solo el segundo escribe clientes_ref; conviene que el usuario de base de datos de la API no tenga permiso de escritura sobre esa tabla, o que el código lo haga imposible por construcción.
• El derecho al olvido (RGPD): cuando un cliente pide ser eliminado, hoy basta un DELETE (que fallaría por las FKs de pedidos). Mañana, servicio-clientes anonimiza su fila y publica cliente.eliminado; servicio-pedidos borra la fila de clientes_ref y anonimiza la dirección de envío de los pedidos antiguos que la ley le obligue a conservar; servicio-notificaciones deja de tener nada que borrar porque nunca almacenó al cliente. La ausencia de FK obliga a diseñar este flujo explícitamente, lo cual es una ventaja: en el monolito estaba implícito y mal resuelto.

Separar el esquema es una cosa; mover los datos que ya existen (miles de pedidos, todo el catálogo) mientras la tienda vende es otra. El procedimiento estándar, aplicado a la extracción del catálogo:

Los puntos delicados:

• Paso 3, sincronización. Mientras convivan las dos copias, la antigua sigue recibiendo escrituras (el equipo de catálogo publica fichas a diario). Hay dos formas de propagarlas: que el monolito publique un evento por cada cambio (producto.actualizado) que el nuevo servicio consume, o captura de cambios (CDC) leyendo el registro de transacciones de PostgreSQL con herramientas como Debezium. TechCorp elige eventos publicados desde el monolito, porque esos mismos eventos harán falta después.
• El riesgo del dual write. La tentación es que el monolito escriba directamente en las dos bases de datos ("actualizo la tabla y el documento en la misma función"). Es un error clásico: no hay transacción que abarque PostgreSQL y MongoDB, así que ante cualquier fallo entre las dos escrituras (caída, timeout, excepción) las copias divergen sin que nadie se entere. La escritura debe ser una sola (en la fuente de verdad) y la propagación, asíncrona y reintentable (evento u outbox, que veremos en 02-05).
• Paso 4, comparación en sombra. Antes de fiarse del nuevo almacén, durante un tiempo se ejecutan las lecturas contra ambos y se comparan resultados en un registro. Las discrepancias revelan errores del script de carga o eventos perdidos.
• La feature flag. CATALOGO_REMOTO es la conmutación del branch by abstraction de 02-02: permite pasar el 1 %, el 10 %, el 100 % de las lecturas al nuevo servicio y volver atrás en segundos.
• Paso 6, no tener prisa. La tabla antigua se conserva en solo lectura unas semanas. Borrarla el mismo día del corte es la forma más rápida de descubrir que un informe mensual la usaba.

Un fragmento del script de carga inicial, ilustrativo:

Observa upsert: true: el script se puede ejecutar varias veces sin duplicar nada. Es la primera aparición práctica de la idempotencia que la lección siguiente convierte en regla.

Con todo lo anterior, así quedan los almacenes. Solo mostramos completos los dos que más protagonismo tendrán en la saga; el resto, resumido.

Compáralo con el pedidos / lineas_pedido de 01-05: han desaparecido las FKs a clientes y productos, han aparecido las copias congeladas y la dirección, los identificadores son texto, y hay dos estados nuevos (STOCK_RESERVADO, PAGADO) que la saga de 02-05 explicará. En 02-05 se añadirá una tabla más a esta base de datos: outbox.

Lo importante: el invariante reservado <= cantidad vive aquí y solo aquí, como restricción de base de datos. En el monolito, lo protegía la cláusula WHERE cantidad - reservado >= $1 escrita en crearPedido, es decir, en el código de otro contexto.

La tabla clave-valor atributos_producto (problema 5 de 01-05) desaparece: cada producto lleva los atributos que le corresponden, y un índice sobre categoria más índices selectivos sobre atributos frecuentes (atributos.color) resuelven la búsqueda con filtros. No hay ninguna referencia a stock ni a pedidos.

• servicio-pagos (PostgreSQL pagos): tabla pagos (pago_id, pedido_id sin FK, importe, estado AUTORIZADO/CAPTURADO/RECHAZADO/REEMBOLSADO, referencia_pasarela, creado_en), con UNIQUE (pedido_id) para no cobrar dos veces.
• servicio-clientes (PostgreSQL clientes): clientes (cliente_id, keycloak_sub, email UNIQUE, nombre, activo) y direcciones (direccion_id, cliente_id FK interna, calle, cp, ciudad, predeterminada).
• servicio-notificaciones: registro mínimo envios (envio_id, pedido_id, tipo, destinatario, enviado_en, estado) para no reenviar; puede ser una tabla pequeña o incluso el propio registro de la cola.

Queda una pregunta que Marta hará en cuanto vea el diseño: "¿y el informe de ventas por categoría y ciudad?". Hoy es un JOIN de cuatro tablas. Mañana los datos están en cinco bases de datos, una de ellas MongoDB.

La respuesta de la arquitectura es que la analítica no se hace contra las bases de datos operativas de los servicios, ni antes ni después de los microservicios (hacerlo era, de hecho, una de las causas de los bloqueos del problema 3). Se construye una base de datos de lectura separada (almacén analítico o data warehouse) alimentada por los eventos que ya publican los servicios (pedido.confirmado con líneas y dirección, producto.actualizado con categoría) o por exportaciones periódicas. Es la misma idea de la vista materializada del apartado 4, llevada a escala de empresa: consistencia eventual (minutos u horas de retraso son aceptables para un informe) a cambio de no tocar los servicios en producción. Se desarrolla la mecánica en 02-05 (CQRS) y no volveremos sobre ello salvo de pasada.

• Separar los servicios y dejar la base de datos compartida "de momento". Ese "momento" dura años. Como mínimo, esquemas y usuarios separados desde el primer servicio extraído.
• Mantener las FKs cruzadas "porque son gratis". No lo son: son la razón por la que el catálogo no puede mudarse a MongoDB ni un servicio migrar su esquema sin coordinarse.
• Replicar todo el modelo del otro servicio. La réplica lleva los campos que necesitas, no la tabla entera. clientes_ref tiene tres columnas, no doce.
• Confundir copia congelada con réplica. El precio de una línea de pedido no debe actualizarse; el nombre del cliente en clientes_ref sí. Documenta cuál es cuál.
• Hacer dual write durante la migración. Una escritura, en la fuente de verdad; la copia se propaga por eventos y se verifica en sombra.
• Usar SERIAL como identificador que viaja entre servicios. Identificadores opacos, generados por el dueño, únicos globalmente.
• Consejo: para cada consulta del monolito que hoy hace JOIN entre áreas, apunta en una tabla: frecuencia, tolerancia a retraso, campos ajenos que necesita, y decide composición / réplica / vista materializada. Esa tabla es tu plan de datos.

Para cada consulta del monolito, indica la alternativa más adecuada (composición de APIs, réplica por eventos o vista materializada) y justifica en una línea: (1) la página de detalle de un pedido para el cliente, que muestra el nombre del cliente y las líneas; (2) el listado del panel de administración "pedidos de hoy" con nombre de cliente, paginado y filtrable por ciudad; (3) el correo de confirmación, que necesita el email del cliente y los nombres de los productos; (4) el informe mensual de ventas por categoría de producto.

pagos.pedido_id pierde su clave foránea a pedidos. Explica qué garantías se pierden y cómo las recupera servicio-pagos por diseño (piensa en: cómo sabe que el pedido existe, qué impide dos pagos para el mismo pedido, y qué pasa si llega un stock.reservado de un pedido que Pagos nunca ha visto).

Escribe el SQL de la base de datos clientes de servicio-clientes (tablas clientes y direcciones) siguiendo las convenciones de esta lección (identificadores opacos, sin FKs cruzadas, restricciones internas explícitas), e indica qué evento debería publicar el servicio cuando un cliente cambia su email y qué servicios lo consumirían.

Ejercicio 1

1. Composición (o incluso nada: el pedido ya guarda las líneas con nombre y precio congelados; para el nombre del cliente, una llamada a GET /clientes/{id} o la réplica clientes_ref). Es una consulta de un solo elemento y debe mostrar el estado actual.
2. Réplica (clientes_ref) para el nombre, y probablemente vista materializada si se filtra por ciudad de la dirección de envío y se combina con datos de otros contextos: paginación y filtros cruzados no funcionan con composición (N+1).
3. Ninguna de las tres en Notificaciones: los datos viajan en el evento pedido.confirmado (email, nombre, líneas con nombre de producto). Notificaciones no consulta ni replica; es conformist (02-03).
4. Vista materializada / almacén analítico alimentado por eventos: consulta agregada, tolerante a retraso, que no debe cargar a los servicios en producción (apartado 8).

Ejercicio 2

Se pierde: (a) la garantía de que el pedido existe; (b) el bloqueo de borrado; (c) el JOIN. Cómo lo recupera Pagos: (a) Pagos no crea pagos por iniciativa propia: reacciona a stock.reservado, que lleva pedidoId e importe, y ese evento solo existe si Pedidos creó el pedido; opcionalmente valida con GET /pedidos/{id} en caso de duda. (b) La restricción UNIQUE (pedido_id) en su propia tabla pagos impide dos cobros para el mismo pedido aunque el evento llegue duplicado (idempotencia, 02-05). (c) Si llega un stock.reservado de un pedido desconocido para Pagos, es la situación normal: Pagos no necesita "haber visto" el pedido antes; el evento es la única entrada. Lo que sí debe hacer es rechazar eventos malformados o de importe inválido y registrar el caso. Y si un pedido se anula, no se borra: Pagos recibirá pedido.cancelado y reembolsará si había cobrado.

Ejercicio 3

Evento: cliente.actualizado con { clienteId, email, nombre, actualizadoEn }. Lo consumiría servicio-pedidos para actualizar clientes_ref (réplica). servicio-notificaciones no lo necesita (recibe el email en cada evento de pedido) y servicio-pagos tampoco (no conoce clientes). Un cliente.eliminado adicional dispararía la anonimización descrita en el apartado 5.

Hemos dado el paso físico que separa de verdad los servicios: una base de datos por servicio. Hemos visto por qué la base de datos compartida concentra todos los acoplamientos, la escalera de aislamiento (esquemas y usuarios separados como paso intermedio, instancias separadas como objetivo, MongoDB para el catálogo y PostgreSQL para el resto por su modelo de datos y su patrón de acceso, con el límite de dos tecnologías), cómo se rompen las claves foráneas cruzadas (pedidos.cliente_id, lineas_pedido.producto_id, stock.producto_id, pagos.pedido_id pasan a referencias opacas de texto, con validación por contrato e identificadores generados por el dueño), qué hacer con los JOIN perdidos (composición de APIs para el detalle, réplica clientes_ref alimentada por eventos para los listados, vista materializada para el panel), quién escribe cada dato y cómo se gestiona su ciclo de vida (incluido el borrado RGPD), cómo migrar sin dual write (carga inicial idempotente, sincronización por eventos, lectura en sombra, feature flag) y el esquema resultante de servicio-pedidos, servicio-inventario y servicio-catalogo.

Ese esquema deja una pregunta abierta a propósito: pedidos.estado admite STOCK_RESERVADO y PAGADO, y reservas tiene expira_en. Son las huellas de lo que ya no existe: la transacción única de crearPedido. La siguiente lección la sustituye por una saga, con sus compensaciones, su máquina de estados, el patrón outbox que garantiza que los eventos salen si y solo si el cambio se guardó, la idempotencia de los consumidores, y las vistas de lectura de CQRS; y decidirá si TechCorp necesita event sourcing (adelanto: por ahora, no).