Todo lo que hemos visto hasta ahora ha sido conceptual: qué es un microservicio, qué se gana y qué se paga, cómo se compara con el monolito y cuándo conviene dar el paso. A partir de aquí, el curso se vuelve práctico, y para que lo práctico tenga sentido necesitamos un caso realista que nos acompañe de principio a fin. Ese caso es TechCorp y su tienda online, techcorp-shop.

En esta lección presentamos el hilo conductor con todo detalle: quién es TechCorp y quiénes son las personas que tomarán las decisiones, cómo es su monolito actual, qué problemas concretos sufre, cuál es el flujo de negocio central que usaremos una y otra vez ("un cliente hace un pedido"), un fragmento real del código actual que servirá de punto de partida, el mapa de servicios que construiremos, el stack tecnológico elegido y una hoja de ruta que explica qué avanzará cada módulo sobre este caso. No vamos a diseñar todavía los límites de los servicios (eso es trabajo del módulo 2) ni a implementar nada (módulo 4): aquí solo fijamos el escenario y las reglas del juego.

1. Quién es TechCorp
2. La tienda hoy: un monolito Node.js/Express con una única PostgreSQL
3. Las seis áreas funcionales
4. Los problemas concretos que sufre TechCorp
5. El flujo central: "un cliente hace un pedido"
6. Un fragmento del monolito actual: crearPedido
7. El mapa objetivo de servicios
8. El stack tecnológico elegido y por qué
9. Hoja de ruta del caso a lo largo del curso
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

TechCorp es una empresa ficticia de comercio electrónico que vende productos de electrónica de consumo (auriculares, altavoces, accesorios, pequeños dispositivos) a través de su tienda online techcorp-shop. Todos los datos que aparecerán en el curso (clientes, productos, importes, pedidos) son inventados.

Datos de contexto que iremos usando:

Dos personas aparecerán constantemente:

• Marta, CTO de TechCorp. Es quien decide la estrategia técnica, quien defiende (o no) las inversiones ante dirección y quien ha llegado a la conclusión, tras aplicar los criterios de la lección anterior, de que la tienda necesita evolucionar hacia microservicios de forma incremental. Marta pondrá las restricciones de negocio: no se puede parar la tienda, no hay presupuesto ilimitado, cada paso tiene que aportar valor.
• Luis, líder del equipo de Pedidos. Es el responsable del área más delicada de la tienda (donde se cruzan clientes, catálogo, stock, pagos y notificaciones) y será nuestro protagonista técnico: la mayor parte del código que escribiremos en el curso será el de servicio-pedidos, y muchas decisiones las veremos desde su punto de vista.

techcorp-shop es un único proyecto Node.js 20 con Express, escrito en JavaScript, que se ejecuta como un solo proceso (replicado en tres servidores idénticos detrás de un balanceador) y que utiliza una única base de datos PostgreSQL con todas las tablas de todas las áreas.

Estructura simplificada del repositorio actual:

Y el esquema de la base de datos, muy resumido:

Fíjate en las claves foráneas cruzadas entre áreas (pedidos.cliente_id → clientes, lineas_pedido.producto_id → productos, pagos.pedido_id → pedidos). Hoy son una comodidad enorme; en el módulo 2 veremos que son también el principal obstáculo para separar los datos.

El monolito agrupa seis áreas de negocio, que hoy son carpetas y tablas dentro del mismo proyecto y que mañana serán servicios:

Estas seis áreas se corresponderán, una a una, con los seis servicios del mapa objetivo. Que la correspondencia sea tan directa es una simplificación deliberada para el curso; en la vida real, encontrar los límites correctos es un trabajo en sí mismo, que abordaremos en el módulo 2.

Marta no quiere microservicios por moda. Los quiere porque la tienda tiene problemas medibles que encajan con las señales de la lección 01-04:

1. Despliegues semanales con miedo. Toda la tienda se despliega los jueves por la noche. La suite de pruebas tarda 40 minutos; el despliegue, con comprobaciones manuales, dos horas. En el último trimestre, cuatro de doce despliegues se revirtieron total o parcialmente. Cualquier corrección urgente espera al jueves siguiente o requiere un despliegue de emergencia de toda la aplicación.

2. Caídas en campañas. En el último Black Friday, el tráfico de navegación por el catálogo saturó los tres servidores. Como el catálogo comparte proceso y base de datos con todo lo demás, la creación de pedidos y los cobros también se cayeron: la tienda no vendió durante 50 minutos en el día de más ventas del año. Para evitarlo, sistemas replicó todo el monolito a diez servidores durante la campaña, pagando por capacidad de pagos y clientes que no hacía falta.

3. Un equipo pisándose. Los desarrolladores de las distintas áreas trabajan sobre el mismo repositorio y las mismas tablas. Cuando el equipo de Notificaciones cambió una consulta sobre pedidos para un nuevo correo, rompió un informe de Pedidos. Cuando Pedidos añadió una columna a lineas_pedido, la migración falló en producción por un bloqueo con una consulta pesada de Catálogo. Los pull requests se atascan por conflictos, y el equipo de Luis calcula que dedica un 20 % del tiempo a coordinarse con otros equipos.

4. Incidentes que se propagan. Un mes antes, un fallo del proveedor de correo hizo que el envío de emails empezara a acumular conexiones abiertas; la fuga de memoria terminó tumbando el proceso entero, incluidos los cobros.

5. Modelo de datos del catálogo forzado. Los productos tienen atributos muy variables (unos tienen talla, otros voltaje, otros compatibilidad) y en PostgreSQL se ha acabado con una tabla atributos_producto genérica de clave-valor incómoda de consultar y de mantener.

Estos cinco problemas son el "porqué" de todo el curso. Cada módulo posterior resolverá alguno de ellos.

De todos los flujos de la tienda, uno los atraviesa todos: un cliente hace un pedido. Es el flujo que más valor tiene para el negocio, el que más áreas implica y el que más problemas concentra. Por eso será el ejemplo recurrente de todo el curso: lo modelaremos, lo dividiremos, lo implementaremos, lo desplegaremos, lo monitorizaremos y lo aseguraremos.

Los pasos, tal como ocurren hoy en el monolito:

1. El cliente, ya identificado, envía su carrito (clienteId y una lista de productoId con cantidades).
2. Se comprueba que el cliente existe y se recupera su dirección.
3. Se consultan los productos para obtener nombre y precio actual.
4. Se comprueba el stock de cada producto y se reserva (se incrementa stock.reservado).
5. Se calcula el total y se crea el pedido en estado PENDIENTE con sus líneas.
6. Se cobra llamando a la pasarela de pago externa y se registra el pago.
7. Si el cobro va bien, el pedido pasa a CONFIRMADO, el stock reservado se descuenta definitivamente y se envía el correo de confirmación.
8. Si el cobro falla, se libera la reserva de stock, el pedido pasa a CANCELADO y se envía un correo de incidencia.

Todo esto ocurre dentro de una única petición HTTP y, casi todo, dentro de una única transacción de base de datos.

Cuando la tienda esté dividida en servicios, este mismo flujo se convertirá en una coreografía de eventos: servicio-pedidos creará el pedido y publicará pedido.creado; servicio-inventario reservará stock y publicará stock.reservado; servicio-pagos cobrará y publicará pago.confirmado; servicio-pedidos confirmará el pedido y publicará pedido.confirmado (o pedido.cancelado si algo falla); y servicio-notificaciones enviará el correo. Esa versión la diseñaremos en el módulo 2 y la construiremos en el 4; de momento, quédate con la versión monolítica y con los nombres de los eventos, que reaparecerán constantemente:

Este es, simplificado pero fiel al espíritu del código real, el controlador Express que hoy implementa el flujo anterior. Léelo con calma: es el punto de partida de todo el curso, y volveremos sobre él para descomponerlo (módulo 2), extraer servicios (módulo 4) y compararlo con el resultado final (módulo 8).

Qué observar en este código, porque cada punto será un tema del curso:

• Una función hace seis cosas de cinco áreas distintas: valida cliente, consulta catálogo, reserva inventario, crea pedido, cobra y notifica. Es fácil de leer, pero cualquier cambio en cualquier área pasa por aquí.
• Acceso directo a tablas de otras áreas (clientes, productos, stock, pagos). Es lo que hace imposible que Notificaciones cambie su esquema sin avisar a Pedidos, y viceversa. La lección 02-04 tratará precisamente de romper esto.
• Una transacción lo protege todo: si el pago falla, el ROLLBACK deshace la reserva de stock y el pedido. Es la comodidad que perderemos al separar bases de datos y que la lección 02-05 sustituirá con una saga.
• Una llamada externa (la pasarela de pago) dentro de la transacción: mientras la pasarela responde (a veces segundos), las filas de stock quedan bloqueadas para todos los demás pedidos. En campañas, esto contribuye a la saturación.
• El envío de correo es síncrono: si el servidor de correo tarda o falla, la respuesta al cliente tarda o falla, aunque el pedido esté perfectamente cobrado. Esto es lo que las notificaciones asíncronas por eventos resolverán en el módulo 3.
• Sin idempotencia: si el cliente pulsa dos veces "comprar", se crean dos pedidos y se cobra dos veces. Hoy lo evita el front-end; en un sistema distribuido, no será suficiente.

Este es el sistema que iremos construyendo. Los nombres, puertos y bases de datos son fijos para todo el curso; los reutilizaremos en el código, en los ficheros de Docker Compose y en los manifiestos de Kubernetes.

Y la infraestructura de apoyo que rodeará a los servicios:

Marta y los líderes de equipo han fijado el stack con dos criterios: continuidad con lo que el equipo ya conoce (para no aprender un lenguaje nuevo a la vez que una arquitectura nueva) y estándares de mercado para el resto de piezas.

Una nota importante para tu aprendizaje: estas elecciones son razonables, no las únicas. En la lección 04-01 discutiremos alternativas (Kafka frente a RabbitMQ, otros lenguajes, otros orquestadores). Aquí simplemente fijamos el terreno para que todos los ejemplos del curso sean coherentes.

Así avanzará la historia de TechCorp módulo a módulo. Cada fila responde a la pregunta "¿qué le pasa a la tienda en este módulo?".

Un detalle que conviene tener presente desde ya: el curso no hace un "big bang". TechCorp no apagará el monolito un viernes para encender seis servicios el lunes. Los servicios se extraerán uno a uno, empezando por el catálogo (la razón de escalado más clara y el menor riesgo), después el flujo de pedidos, y el monolito irá adelgazando hasta desaparecer. Ese proceso incremental se detalla en la lección 08-01.

• Perder de vista el porqué. Cuando en el módulo 5 estés peleándote con un manifiesto de Kubernetes, recuerda los cinco problemas del apartado 4: cada pieza de infraestructura está ahí para resolver uno de ellos, no por sí misma.
• Idealizar el punto de llegada. El mapa de servicios del apartado 7 es el objetivo, pero se construirá paso a paso, y algunas decisiones se revisarán por el camino (es lo normal en un proyecto real).
• Despreciar el código del monolito. crearPedido es un código razonable para un monolito; no es "malo", es inadecuado para el problema que TechCorp tiene ahora. Entenderlo bien es la clave para descomponerlo bien.
• Cambiar los nombres. Mantén los nombres de servicios, puertos y eventos exactamente como aparecen en las tablas de esta lección; el resto del curso los da por supuestos.
• Consejo: guarda una copia mental (o real) del diagrama de secuencia del apartado 5. Lo compararás con su versión en eventos en el módulo 2 y con la traza distribuida real en el módulo 6, y esa comparación es una de las mejores formas de entender qué cambia con los microservicios.

Sin mirar el diagrama de secuencia, escribe en orden los ocho pasos del flujo "un cliente hace un pedido" tal como ocurre hoy en el monolito, e indica para cada paso a qué área funcional pertenece.

Sobre el fragmento del apartado 6, responde:

1. ¿Qué tablas consulta o modifica que no pertenecen al área de pedidos?
2. ¿Qué ocurre si la pasarela de pago tarda 15 segundos en responder? ¿A quién afecta?
3. ¿Qué ocurre si el envío del correo falla después del COMMIT? ¿Qué ve el cliente y qué queda en la base de datos?

Para cada uno de los cinco problemas del apartado 4, indica qué módulo (o módulos) del curso lo abordarán y con qué pieza del mapa objetivo o del stack se relaciona.

Ejercicio 1

1. El cliente envía el carrito → Pedidos (punto de entrada).
2. Comprobar cliente y recuperar dirección → Clientes.
3. Consultar productos y precios → Catálogo.
4. Comprobar y reservar stock → Inventario.
5. Calcular total y crear pedido PENDIENTE → Pedidos.
6. Cobrar en la pasarela y registrar el pago → Pagos.
7. Confirmar pedido, descontar stock y enviar correo → Pedidos, Inventario y Notificaciones.
8. Si el cobro falla: liberar reserva, cancelar y notificar incidencia → Inventario, Pedidos y Notificaciones.

Ejercicio 2

1. clientes (área de clientes), productos (catálogo), stock (inventario) y pagos (pagos). Solo pedidos y lineas_pedido son propias.
2. La transacción sigue abierta durante esos 15 segundos, con las filas de stock de esos productos bloqueadas por el UPDATE. Cualquier otro pedido que incluya alguno de esos productos se queda esperando. En una campaña, muchos pedidos esperando bloqueos agotan las conexiones y el sistema entero se degrada. Además, el cliente ve la página "cargando" durante 15 segundos.
3. El pedido está confirmado, cobrado y con stock descontado en la base de datos (el COMMIT ya se ha ejecutado). Pero correo.enviar lanza una excepción, el catch ejecuta un ROLLBACK (que ya no deshace nada, porque la transacción terminó) y responde al cliente con un 500. El cliente cree que su compra ha fallado, aunque se le ha cobrado; probablemente vuelva a intentarlo y se le cobre dos veces. Es un ejemplo perfecto de por qué las notificaciones deben ser asíncronas y desacopladas.

Ejercicio 3

En esta lección hemos presentado a fondo el caso que vertebra el curso: TechCorp, una tienda online que hoy es un monolito Node.js/Express sobre una única PostgreSQL con seis áreas funcionales, y que sufre problemas concretos y medibles: despliegues semanales temidos, caídas en campañas por saturación del catálogo, equipos que se pisan sobre el mismo código y las mismas tablas, incidentes que se propagan de áreas secundarias a las críticas y un modelo de datos forzado en el catálogo. Hemos recorrido paso a paso el flujo central "un cliente hace un pedido" y hemos leído el código real de crearPedido, que concentra en una sola función y una sola transacción el trabajo de cinco áreas: ese fragmento es nuestro punto de partida. Hemos fijado el mapa objetivo (seis servicios con sus puertos y bases de datos más un gateway), el stack tecnológico y sus razones, los cinco eventos del flujo de pedido y una hoja de ruta módulo a módulo.

Con el escenario definido, el módulo 2 empieza el trabajo de verdad: diseñar los microservicios. Partiremos de los principios de diseño, aprenderemos a descomponer el monolito de TechCorp, definiremos sus bounded contexts, decidiremos cómo repartir los datos entre servicios y sustituiremos la gran transacción de crearPedido por una saga coordinada mediante eventos. Marta ha tomado la decisión; a partir de ahora acompañamos a Luis y a su equipo en la ejecución.