Hemos llegado al final. TechCorp ha pasado de un monolito con cinco problemas medibles (01-05) a seis servicios operados con SLOs, desplegados once veces al día y asegurados por capas; hemos contado la migración (08-01), escrito el sistema completo (08-02) y lo hemos desplegado y operado (08-03). Esta última lección no añade nada nuevo al sistema: destila lo aprendido para que te lo lleves a tu propio contexto. Primero, las lecciones de TechCorp organizadas por dimensión, cada una en la forma más honesta posible ("qué hicimos, qué salió mal, qué haríamos distinto"). Después, el catálogo de antipatrones que hemos visto y cómo reconocerlos a tiempo. Luego, una lista consolidada de buenas prácticas con la lección donde se explica cada una, lo que TechCorp haría en su fase 2 y con qué criterio, y una guía para el alumno: cómo decidir, por dónde empezar, cómo practicar con el entorno del curso y qué leer después. Y el cierre: el recorrido módulo a módulo y las palabras finales de Marta y Luis.

1. Lecciones aprendidas por dimensión
2. Catálogo de antipatrones y cómo detectarlos
3. Lista consolidada de mejores prácticas
4. Qué haría TechCorp en la fase 2
5. Guía para el alumno: aplicar el curso a tu contexto
6. Lecturas y recursos recomendados
7. Cierre del curso (en la conclusión)

Cada tabla resume una dimensión del curso. La columna "qué haríamos distinto" es la más útil: es lo que TechCorp escribiría en el postmortem del proyecto.

Todos han aparecido en el curso, casi todos en TechCorp. La columna "cómo detectarlo" es una prueba que puedes aplicar a tu sistema mañana.

Veinticinco puntos, agrupados, con la lección de referencia. Úsala como checklist de revisión de arquitectura o de un servicio nuevo.

Decisión y diseño

1. Adopta microservicios por problemas medibles, no por moda; construye los cuatro prerrequisitos sobre el monolito y modularízalo primero (01-04, 02-02, 08-01 fase 0).
2. Corta por capacidades de negocio y bounded contexts; valida con event storming y la matriz tabla × área (02-02, 02-03).
3. Un servicio = sus datos: base de datos (o esquema) propia, ids opacos, sin FK cruzadas, réplicas de lectura por eventos (02-04).
4. Sustituye la transacción distribuida por una saga con máquina de estados explícita, compensaciones como eventos y un vigilante (02-05, 06-03 §9).
5. Extrae en orden de valor/riesgo/dependencias con strangler fig tras un gateway y branch by abstraction con flags; nunca borres lo antiguo el día del corte (02-02, 08-01).

Comunicación 6. Contratos primero (OpenAPI/AsyncAPI), errores RFC 7807 con codigo, 202 para procesos asíncronos, ETag para polling (03-01). 7. Eventos con sobre estándar (eventoId, tipo, version, ocurridoEn), topic exchange, cola por consumidor con reintento diferido y DLQ (03-02, 06-03 §8). 8. Outbox transaccional para publicar; procesarUnaVez + idempotencia de negocio (UNIQUE) para consumir; Idempotency-Key en los POST (02-05 §7-8, 04-04, 08-02). 9. Gateway delgado; composición en BFF o servicio; ACL en cada frontera (03-04, 02-03). 10. Versiona: añade sin quitar, /v2/ solo para incompatibles, Deprecation/Sunset, upcasting de eventos, pactos HTTP y de mensajes con can-i-deploy (03-06, 04-05, 05-03 §4).

Implementación 11. Plantilla de servicio + librería técnica versionada; el negocio no se comparte (04-01, 02-02 §6). 12. crearApp sin listen, inyección de dependencias por parámetro, capas hacia dentro (04-02). 13. Configuración validada al arrancar, fail-fast, secretos fuera del código y de la imagen (04-03, 07-03 §7). 14. Pirámide: unitarias del dominio, componente con dobles, integración con Testcontainers, contrato con Pact, una E2E (04-05). 15. Ninguna llamada externa dentro de una transacción; transacciones cortas y consulta por clave de idempotencia ante la duda (01-05, 08-02 §4).

Plataforma y despliegue 16. Imágenes multi-stage, no root, etiquetadas por sha y semver, escaneadas y firmadas; nunca latest (05-01, 07-04 §2). 17. Kustomize base + overlays por entorno; Helm para terceros con values versionados; sondas, securityContext, PDB, requests reales (05-02, 06-04, 07-04). 18. GitOps: producción cambia por PR; Argo CD sincroniza; rollback = revertir commit (05-03 §6). 19. Despliegues progresivos por servicio (rolling, canary, blue-green) con expand/contract y compatibilidad de eventos (05-04). 20. Workflow de CI reutilizable y versionado; la regla de Luis (05-03 §11).

Operación y seguridad 21. Logs estructurados con redact, métricas RED y de negocio con etiquetas acotadas, trazas con contexto propagado por HTTP y por eventos (06-01, 06-02). 22. Timeouts siempre, reintentos solo de lo transitorio con backoff, circuit breaker, bulkhead, DLQ con runbook (06-03). 23. SLOs con presupuesto de error, alertas por síntoma y burn rate, guardia con runbooks, postmortems sin culpa con acciones (06-05). 24. Identidad portable (OIDC/JWT) verificada en el gateway y en cada servicio; autorización por rol, scope y propietario; TLS en todas partes; webhooks firmados (07-01, 07-02). 25. Validación estricta de entrada, RGPD por diseño (minimización, retención, supresión), auditoría inmutable, secretos por operador, NetworkPolicies deny-all, RBAC mínimo, y una lista de pendientes honesta (07-03, 07-04).

Nada de esto es urgente; cada punto tiene un criterio que dice cuándo abordarlo. Es la diferencia entre una hoja de ruta y una lista de deseos.

Decidir. Vuelve a la matriz de 01-04 y responde con datos, no con opiniones:

Cuatro o más "sí" con los prerrequisitos listos: extrae de forma incremental empezando por la razón más clara. Menos: monolito modular y revisión en seis meses. Y recuerda que la lista de 01-04 tiene señales de alarma (equipo de tres personas, "porque lo hace Netflix", sin automatización) que anulan todo lo demás.

Por dónde empezar (si decides seguir): en este orden, y sin saltarte ninguno: (1) los cuatro equipos —o los que tengas— con propiedad clara; (2) CI e imagen del monolito; (3) gateway delante y observabilidad mínima; (4) matriz tabla × área y monolito modular; (5) primera extracción por valor/riesgo/dependencias con carga inicial, eventos, sombra y flag; (6) SLO y alerta del servicio nuevo antes de darlo por hecho; (7) plantilla y librería antes del segundo servicio.

Cómo practicar. El entorno del curso está pensado para reproducirse:

• Levanta TechCorp en local con el compose.yaml de 08-03 §2, obtén un token de Keycloak y sigue a ped-88213 por Jaeger, Grafana y Loki como en 08-03 §5. Rompe cosas: para servicio-pagos y observa el vigilante y la DLQ; publica un evento mal formado con publicarEvento.js y reprocésalo; agota el stock de p-802.

• Ejercicios de extensión propuestos, de menor a mayor: cupones y promociones (01-03, 02-02 ej. 2, 08-01 §11): primero como módulo de Pedidos, después decide con criterio si merece servicio; devoluciones: nuevo estado del pedido, pago.reembolsado como rama habitual, stock.repuesto, correo, auditoría; envíos: un servicio-envios que consuma pedido.confirmado, hable con un transportista ficticio (ACL, webhook firmado, reintentos) y publique pedido.enviado/pedido.entregado que Notificaciones y la analítica consuman; v2 de pedido.creado con upcasting y pactos de mensajes; Argo Rollouts para el canary de Pedidos con análisis de slo:pedidos_error_ratio.
• Repite el módulo 6 sobre tu propia extensión: métricas, SLO, alerta, runbook y un game day en el que un compañero rompa algo sin avisar.

Sin URLs (cambian); busca por título y proyecto. Libros:

• Sam Newman, Building Microservices (2.ª ed.) y Monolith to Microservices: la referencia general y el manual del strangler fig que TechCorp siguió (módulos 1, 2 y 8).
• Chris Richardson, Microservices Patterns: sagas, outbox, CQRS, API composition; el sitio microservices.io del autor cataloga los patrones (02-05, 03-04).
• Eric Evans, Domain-Driven Design; Vaughn Vernon, Implementing Domain-Driven Design; Vlad Khononov, Learning Domain-Driven Design: bounded contexts, mapa de contextos, agregados (02-03).
• Martin Kleppmann, Designing Data-Intensive Applications: consistencia, replicación, mensajería, la base teórica de 02-04 y 02-05.
• Gregor Hohpe y Bobby Woolf, Enterprise Integration Patterns: mensajería, DLQ, idempotencia (03-02, 06-03).
• Michael Nygard, Release It! (2.ª ed.): timeouts, circuit breaker, bulkhead, estabilidad (06-03).
• Betsy Beyer y otros (Google), Site Reliability Engineering y The Site Reliability Workbook: SLOs, burn rate, guardias, postmortems (06-05).
• Nicole Forsgren, Jez Humble y Gene Kim, Accelerate: las métricas DORA (05-03, 08-01 §10).
• Matthew Skelton y Manuel Pais, Team Topologies: equipos alineados a flujo y equipo de plataforma (02-01, 08-04 §1.1).
• Jez Humble y David Farley, Continuous Delivery; Marko Lukša, Kubernetes in Action: la base de los módulos 5 y 8.
• Neal Ford, Mark Richards, Pramod Sadalage y Zhamak Dehghani, Software Architecture: The Hard Parts: granularidad, datos y sagas con trade-offs explícitos.

Documentación oficial y proyectos que conviene tener a mano: Node.js y Express; PostgreSQL y MongoDB; RabbitMQ (guías de fiabilidad, DLX y TTL); Docker y Compose; Kubernetes (conceptos, Kustomize), Helm, kind, KEDA, Argo CD y Argo Rollouts, ingress-nginx, cert-manager, External Secrets Operator; GitHub Actions; Prometheus, Grafana, Loki, OpenTelemetry (JavaScript SDK) y Jaeger; Keycloak; Pact (incluidos los pactos de mensajes) y el Pact Broker; Trivy y Sigstore/cosign; OWASP API Security Top 10; The Twelve-Factor App; y las especificaciones OpenAPI, AsyncAPI, RFC 7807 y W3C Trace Context.

• Convertir la lista de mejores prácticas en dogma. Cada punto del apartado 3 tiene una lección con su contexto y sus trade-offs; aplicado sin el contexto (por ejemplo, outbox en un servicio que no publica nada crítico) añade complejidad sin beneficio. Lee la lección antes de imponer la práctica.
• Copiar la arquitectura final de TechCorp en lugar de su método. Seis servicios, RabbitMQ y Kubernetes son la respuesta a los cinco problemas de 01-05 con 25 técnicos; con tres personas y un dominio cambiante, la respuesta correcta de la matriz de 01-04 es un monolito modular.
• Confundir "fase 2" con "pendiente". Mesh, event sourcing, gRPC o Go tienen un criterio de activación; abordarlos antes de que se cumpla es el "porque lo hace Netflix" que 01-04 avisaba.
• Postmortem sin acciones o acciones sin fecha. Las tablas del apartado 1 son postmortems del proyecto; su valor está en la columna "qué haríamos distinto" convertida en tareas con dueño.
• Practicar solo el camino feliz. El entorno local sirve para romper: para Pagos, agota stock, publica eventos mal formados, rota un secreto. Lo que no has visto fallar en local lo verás fallar en producción.
• Consejo: guarda tu propia versión de las tablas del apartado 1 desde el primer día de tu proyecto, aunque estén casi vacías. La disciplina de rellenarlas cada trimestre vale más que cualquier herramienta.

Aplica la matriz del apartado 5 a un sistema que conozcas (el de tu trabajo, un proyecto personal o, si no tienes ninguno, un sistema de reservas de un hotel con 4 técnicos). Responde a las cinco preguntas con datos concretos, indica qué recomendación sale y, si es "extraer", cuál sería el primer servicio y qué haría tu fase 0.

Un equipo describe su sistema así: "Tenemos ocho servicios en Kubernetes. Comparten una base de datos PostgreSQL con esquemas separados por servicio, pero el servicio de informes hace JOIN entre esquemas. Desplegamos los ocho juntos cada dos semanas porque un cambio en la librería modelos-comunes obliga a actualizar todos. Los servicios se llaman por HTTP en cadena y, cuando el de clientes tarda, todo tarda. Cada servicio reintenta las llamadas fallidas tres veces seguidas." Identifica todos los antipatrones del apartado 2 que aparecen, ordénalos por el daño que hacen y propón para cada uno la primera acción, con la lección de referencia.

Marta tiene presupuesto para dos iniciativas de la tabla del apartado 4 el próximo semestre. Con los datos del curso (08-01 §10-11, 08-03 §11, SEGURIDAD.md), elige dos, justifica con el criterio de cada una y explica por qué descartas al menos otras tres que parecen atractivas.

Ejercicio 1. No hay una única respuesta; la solución es el método. Para el hotel de 4 técnicos: (1) un equipo, sin estorbos → no; (2) probablemente sin CI completo ni observabilidad → no; (3) reservas y facturación tienen cargas parecidas; quizá el motor de disponibilidad en temporada alta → débil; (4) dominio conocido → sí; (5) la velocidad la frena la falta de pruebas, no el despliegue → no. Resultado: monolito modular con módulos por capacidad (reservas, facturación, disponibilidad, clientes), CI, contenedor, observabilidad y SLIs desde ya; revisar en 6-12 meses. Si en tu sistema real salen cuatro "sí" con prerrequisitos listos, el primer servicio es el que tenga la razón más clara y menos dependencias (el "catálogo" de tu dominio) y la fase 0 es la lista del apartado 5 ("por dónde empezar").

Ejercicio 2. Por daño: (1) Base de datos compartida (los JOIN del servicio de informes cruzan esquemas: cualquier cambio de esquema rompe informes) → matriz tabla × servicio y BD de lectura para informes alimentada por eventos (02-02 §3.3, 02-04 §8); (2) Librería de modelos compartida + monolito distribuido (ocho servicios desplegados juntos por modelos-comunes) → sustituir por contratos por servicio y una librería solo técnica versionada; cada servicio define sus DTOs (02-02 §6, 03-06); (3) Sincronía en cadena con reintentos inmediatos (todo tarda cuando tarda clientes; tres reintentos seguidos multiplican la carga: tormenta de reintentos) → timeouts con presupuesto, circuit breaker, reintentos con backoff solo de lo transitorio, y sustituir las llamadas no necesarias en la petición por eventos o réplicas de lectura (06-03, 02-04 §4, 03-02); (4) Despliegue conjunto cada dos semanas (síntoma, no causa) → desaparece al resolver 1-2; medir DORA para comprobarlo (05-03 §12). No aparecen (o no se sabe): gateway gordo, secretos, cardinalidad; preguntar.

Ejercicio 3. Una respuesta defendible: (a) FinOps — criterio "ya": la factura es de 2.760 €/mes con palancas identificadas de ~800 € (08-03 ej. 3); coste de la iniciativa bajo (etiquetas y un informe); retorno inmediato que además financia lo demás. (b) Pendientes de SEGURIDAD.md (cosign en admisión, PSA enforce, ESO para todos) — criterio "trimestre siguiente"; riesgo conocido, coste acotado, y desbloquea la auditoría de Pagos que a su vez activará el mesh. Descartes: mesh/mTLS ahora — su criterio (auditoría o >12 servicios) no se cumple aún y cuesta operar (05-05); event sourcing — nadie ha pedido el historial completo y la auditoría de 07-03 cubre lo sensible; Go para Inventario — no hay coste ni latencia medidos que lo justifiquen (regla de Marta); gRPC Pedidos↔Inventario — la saga cumple su SLO de 60 s con p95 de 3 s; IDP — con 6 servicios y un README, no compensa. Lo importante no son las dos elegidas sino que cada descarte se apoye en el criterio de la tabla y no en el atractivo de la tecnología.

El recorrido, módulo a módulo. En el módulo 1 aprendimos qué es un microservicio, qué se gana y qué se paga, cómo se compara con el monolito, cuándo tiene sentido dar el paso y conocimos a TechCorp: un monolito con cinco problemas y una función, crearPedido, que hacía seis cosas de cinco áreas. En el módulo 2 diseñamos: principios y acoplamientos, descomposición con event storming y la matriz de tablas, bounded contexts y el mapa de contextos, una base de datos por servicio y la migración sin dual write, y la saga por coreografía con outbox e idempotencia que sustituyó a la transacción. En el módulo 3 hicimos hablar a los servicios: contratos REST con 202, ETag e Idempotency-Key; RabbitMQ con su topología y sus DLQ; gRPC y GraphQL como candidatos; el gateway y el BFF; descubrimiento y sondas; versionado y pactos. En el módulo 4 escribimos código: la plantilla y la librería, servicio-catalogo, la configuración validada, servicio-pedidos con su outbox y sus consumidores, y la pirámide de pruebas. En el módulo 5 lo empaquetamos y desplegamos: Docker y Compose, Kubernetes con Kustomize, CI/CD con GitHub Actions, Pact Broker y Argo CD, despliegues progresivos, y la evaluación honesta del mesh. En el módulo 6 lo hicimos operable: logs, métricas y trazas; resiliencia y recuperación; escalado; SLOs, alertas, guardias, runbooks y el postmortem de INC-2031. En el módulo 7 lo aseguramos por capas: Keycloak y JWT, TLS y firmas, código validado y RGPD, plataforma endurecida. Y en el módulo 8 lo unimos: la migración contada en orden, los cuatro servicios que faltaban, el sistema desplegado y operado, y estas lecciones.

Palabras de Marta. "Cuando presenté el plan en julio de 2025 me preguntaron por qué no reescribíamos la tienda de una vez. Trece meses después, la respuesta está en los números que no tuvimos que explicar: ningún día sin vender, once despliegues al día, un incidente serio que duró cuarenta minutos y del que aprendimos más que de dos años de jueves por la noche. Pero lo que más valoro no está en la tabla: hoy cada equipo sabe qué es suyo, lo mide y lo mejora sin pedir permiso. Los microservicios fueron el medio; el fin era una organización que pudiera cambiar la tienda cada día sin miedo. Si tuviera que resumir el proyecto en una frase para otra CTO: no empieces por los servicios, empieza por los deberes; y no borres nada el día del corte."

Palabras de Luis. "Yo me quedo con tres cosas. La primera, que la mejor decisión técnica del año fue la menos vistosa: devolver las escrituras de stock y pagos a su dueño dentro del monolito antes de mover una línea de servidor. La segunda, que casi todo lo que nos salvó en producción era aburrido y estaba escrito antes de necesitarlo: el UNIQUE (pedido_id), el procesarUnaVez, el vigilante, la clave de idempotencia hacia la pasarela, la cola de reintento. Y la tercera, que la regla de 'si se hace más de una vez por servicio, se automatiza antes del segundo' es más fácil de decir que de cumplir —el ci.yml se copió tres veces— y aun así es la que hace que seis servicios los pueda operar un equipo de veinticinco personas. A quien esté empezando: leed crearPedido de 01-05 otra vez, ahora que sabéis en qué se convirtió. Todo el curso está en la distancia entre esas 80 líneas y ped-88213 cruzando cuatro bases de datos en tres segundos."

Para ti. Has recorrido el mismo camino que TechCorp, con sus decisiones y sus tropiezos. Lo que te llevas no es una lista de tecnologías —cambiarán— sino un método: medir antes de decidir, hacer los deberes antes de dividir, cortar por capacidades y datos, comunicar por contratos y eventos idempotentes, automatizar antes del segundo uso, desplegar en pequeño y a menudo, observar y acordar qué es "ir bien", asegurar por capas y aprender por escrito de cada incidente. Levanta TechCorp en tu portátil, rómpela, extiéndela con cupones, devoluciones o envíos, y después aplica el método a tu propio sistema, empezando por la fase 0. Los microservicios no son el destino; son una forma de que tu organización pueda cambiar su software con confianza, un pedido —y un despliegue— cada vez. Gracias por llegar hasta aquí, y buena suerte con tu propia migración.