Son las 11:40 de un jueves. Un cliente escribe: «he intentado pagar el pedido y me ha dado un error». Nada más. Con lo que tienes hoy en src/app.js —ese console.log de la posición 5 que llevamos cinco lecciones prometiendo sustituir— la investigación consiste en buscar a mano entre miles de líneas de texto plano algo parecido a POST /v1/pedidos/ped_5001/pago → 500 (312 ms), sin saber qué cliente era, sin poder filtrar por estado, sin ver el error que lo causó y sin manera de relacionarlo con la consulta SQL que falló.

Peor todavía: la mayoría de las veces ni siquiera te enteras. Los problemas se descubren porque un cliente se queja, no porque el sistema avise. Y las decisiones que llevamos tomando desde 04-01 —los límites de 04-04, la caché de 04-06, la deuda de diseño de 04-01— dependen de datos que ahora mismo no estás recogiendo.

Esta lección cierra el módulo 4 con la capa que hace gobernable todo lo demás. Sustituiremos el console.log por pino con logs estructurados y correlación por trazaId, instrumentaremos la API con prom-client y expondremos /metricas, veremos las trazas distribuidas de un POST /v1/pedidos completo, distinguiremos liveness de readiness en /salud, y definiremos qué alertar y qué mirar el día del lanzamiento.

Advertencia. Los logs son uno de los lugares donde más fácilmente se filtran datos personales y credenciales, con consecuencias legales bajo el RGPD. La redacción de campos sensibles y la política de retención de esta lección son un punto de partida; cualquier despliegue real requiere revisión de compliance y de seguridad. Todos los datos son ficticios.

1. Monitorización frente a observabilidad
2. Los tres pilares y qué pregunta responde cada uno
3. Logs estructurados: por qué JSON y no texto
4. pino y el logger de Tienda Aroma
5. Qué registrar siempre y qué no registrar nunca
6. Redacción automática de campos sensibles
7. El middleware src/middleware/registro.js
8. Correlación extremo a extremo con Aroma-Traza-Id
9. Errores 5xx: qué se loguea frente a qué se devuelve
10. Métricas: las cuatro señales de oro y el método RED
11. Tipos de métrica y por qué el histograma
12. Instrumentar con prom-client y exponer /metricas
13. Cardinalidad: por qué ped_5001 revienta el sistema
14. Trazas distribuidas: spans, contexto y traceparent
15. Una traza de POST /v1/pedidos
16. Comprobaciones de salud: liveness y readiness
17. Alertas útiles, SLO y presupuesto de error
18. El panel mínimo del día del lanzamiento
19. El stack habitual
20. Balance del módulo 4

La monitorización es necesaria y no basta. Los sistemas modernos fallan de formas que nadie previó: una interacción entre el rate limiting y un cliente concreto, una consulta que se degrada solo con cierta distribución de datos, un webhook que se atasca únicamente cuando RápidoEnvíos va lento.

La definición operativa que sirve para trabajar: un sistema es observable si puedes responder preguntas nuevas sobre su comportamiento sin desplegar código nuevo. Si para entender un incidente tienes que añadir un console.log y esperar a que vuelva a pasar, tu sistema no es observable.

El flujo de trabajo real de un incidente los usa en este orden:

1. Una métrica dispara la alerta: la tasa de error de POST /v1/pedidos/{id}/pago ha subido.
2. Una traza de una petición fallida muestra dónde se rompe: la llamada a la pasarela.
3. Un log con el trazaId de esa traza da el detalle: el mensaje exacto del error y el clienteId.

Por eso los tres tienen que estar correlacionados. Tres sistemas excelentes sin un identificador común valen mucho menos que tres sistemas mediocres que comparten el trazaId. Y ese identificador ya lo tenemos: Aroma-Traza-Id, desde 03-02.

Lo que emite hoy nuestro middleware:

Lo que debería emitir:

La única desventaja real —la legibilidad en desarrollo— se resuelve con un formateador, así que no hay motivo para no estructurar.

Dos reglas de fondo que evitan la mayoría de los problemas:

Los logs son eventos, no frases. "El usuario cli_842 ha creado el pedido ped_5001" obliga a extraer los identificadores con una expresión regular. {"evento":"pedido_creado","clienteId":"cli_842","pedidoId":"ped_5001"} es consultable.

La ruta se registra como plantilla, no como URI. "/v1/pedidos/:id/pago", nunca "/v1/pedidos/ped_5001/pago". Si registras la URI real, no puedes agrupar: cada pedido produce una ruta distinta y las estadísticas por endpoint son imposibles. El identificador va en su propio campo, donde sí sirve para filtrar.

pino es el logger estándar de facto en Node: escribe JSON, es extremadamente rápido —serializa fuera del hilo crítico— y trae de serie la redacción de campos sensibles y los loggers hijo.

Cinco decisiones explicadas:

Los niveles de pino son trace (10), debug (20), info (30), warn (40), error (50) y fatal (60). El criterio de Tienda Aroma:

Un error frecuente: registrar los 4xx como error. Un 404 o un 400 son comportamiento normal de la API, no fallos del sistema. Si los marcas como error, tus alertas se llenarán de ruido y dejarás de mirarlas. Solo los 5xx son error.

base añade servicio, version, entorno e instancia a cada línea. Sin eso, en un sistema con varias instancias no sabrás cuál emitió qué, ni podrás distinguir un problema de un despliegue concreto.

Salida a stdout. No a un fichero. En un despliegue moderno, el proceso escribe a la salida estándar y quien recoge, rota y envía los logs es la plataforma. Escribir a fichero desde la aplicación complica la rotación, los permisos y los contenedores.

Dos matices que no son obvios:

La IP es un dato personal bajo el RGPD. Registrarla suele estar justificado por seguridad (interés legítimo), pero exige una política de retención corta y documentada. Una opción prudente es guardar un hash con sal en lugar de la IP, que permite correlacionar sin identificar.

El clienteId también es un identificador personal, pero es seudónimo y necesario para operar. Se registra el identificador (cli_842), nunca el nombre ni el correo: si necesitas saber quién es, se consulta la base de datos con los controles de acceso correspondientes.

Retención. Los logs se conservan un tiempo limitado y documentado —30, 90, 180 días según el tipo— porque cada día de retención de más es riesgo y coste. Y hay que recordar que los logs entran en el ámbito del derecho de supresión del RGPD, otra razón para no meter en ellos datos identificativos.

La redacción manual falla siempre, porque basta con que alguien añada un campo nuevo o registre un objeto entero:

Por eso redact de pino, ya configurado, funciona a nivel del logger: se aplique donde se aplique, esos caminos se censuran.

Los comodines (*.contrasena) cubren cualquier profundidad, lo que atrapa objetos anidados que no habías previsto.

Dos refuerzos que conviene añadir:

Una prueba que lo verifique. La redacción es de esas cosas que se rompen en un refactor sin que nadie lo note:

Un escáner en la integración continua que busque patrones de secreto en los logs de las pruebas. Es la misma idea que el escáner de secretos del repositorio en 04-02.

Aquí sustituimos por fin el console.log de la posición 5.

El punto 4 es el más importante para la seguridad: por defecto, pino-http registra todas las cabeceras de la petición, incluida Authorization. La lista blanca de serializadores es lo que lo impide, y es defensa en profundidad junto con redact.

Un logger hijo es un logger que arrastra automáticamente un contexto fijo. pino-http lo crea en req.log, y a partir de ahí cualquier línea que escribas dentro de la petición lleva el trazaId sin que tengas que pasarlo:

Pasar req.log al servicio es la forma de que las capas internas registren con el mismo contexto sin conocer HTTP. La alternativa —AsyncLocalStorage de Node— evita el paso explícito y es lo que usan las soluciones más avanzadas; para un proyecto de este tamaño, pasar el logger es más simple y más explícito.

Por qué el registro en la 5 y las métricas en la 6:

• Después de CORS (4): si CORS rechaza algo, no hay nada que registrar como petición de la API.
• Antes del rate limiting (7): si fuera después, los 429 no se registrarían ni se contarían, y quedarías ciego justo durante un ataque.
• Antes del parser (9): para registrar también las peticiones con JSON mal formado, que producen un 400 y son señal de un cliente roto.
• Las métricas justo después del registro, para medir todas las peticiones que se registran, sin desfase entre ambos.

El trazaId que emitimos desde 03-02 cobra ahora todo su sentido. Su recorrido:

La validación del formato del punto 1 no es paranoia: sin ella, un atacante puede inyectar saltos de línea en la cabecera y falsificar líneas de log completas (log injection), o meter cargas útiles que exploten el visor de logs.

En la SPA, el ciclo se cierra mostrando el identificador al usuario:

Y para que eso funcione, Aroma-Traza-Id tenía que estar en exposedHeaders de 04-05. Todas las piezas encajan.

En 03-07 prometimos que el trazaId sería el puente entre lo que ve el cliente y lo que ve el equipo. Aquí se materializa.

La asimetría, en una tabla:

Fíjate en la última fila: ni siquiera al equipo se le registra el cuerpo. La tentación de «guardar todo por si acaso» es exactamente cómo acaban las contraseñas en un sistema de logs con retención de un año.

Las cuatro señales de oro (del libro de SRE de Google):

El método RED es la versión simplificada para servicios de petición-respuesta, y es la que se aplica a una API REST:

• Rate: peticiones por segundo.
• Errors: peticiones fallidas por segundo.
• Duration: distribución de la latencia.

Con esas tres, por ruta y por código de estado, cubres el 90 % de lo que necesitas de una API. La saturación se añade como métricas de recursos: memoria del proceso, event loop, pool de conexiones.

Un matiz que evita un error común sobre la latencia: hay que medirla separando los éxitos de los errores. Un 401 responde en 2 ms, así que una avalancha de 401 mejora tu latencia media mientras el servicio está roto. Separar por estado lo evita.

Por qué el histograma y no la media. Como vimos en 04-06, la media miente. Pero además, si cada instancia enviara su media, esas medias no se pueden combinar correctamente: la media de las medias no es la media global salvo que todas tengan el mismo número de muestras.

Un histograma resuelve las dos cosas. Se definen cubos y se cuenta cuántas observaciones caen en cada uno:

Los cubos sí son sumables entre instancias, y el percentil se calcula después interpolando. En PromQL:

La precisión depende de los cubos: si el p99 real es 180 ms y tus cubos saltan de 100 ms a 500 ms, obtendrás una interpolación pobre. Los cubos se eligen a partir de tu presupuesto de latencia (04-06), poniendo fronteras alrededor de los valores que te importan.

/metricas va fuera de /v1, igual que /salud: no forma parte del contrato de negocio ni se versiona con él. Y debe estar protegido: revela tus rutas internas, tus versiones, tu volumen de pedidos y tus tasas de error, información valiosa tanto para un competidor como para un atacante. Se responde 404 en lugar de 401 para no confirmar siquiera que existe. En un despliegue real, además, se expone solo en la red interna o en un puerto distinto no publicado.

Ejemplo de instrumentación de negocio:

Las métricas de negocio son las más valiosas y las que casi nadie pone. «Los pedidos por minuto han caído a cero» detecta incidentes que ninguna métrica técnica ve: la API responde 200, la CPU está bien, y sin embargo un cambio en la SPA ha roto el botón de comprar.

La cardinalidad de una métrica es el número de combinaciones distintas de etiquetas. Cada combinación es una serie temporal independiente, con su propia memoria y su propio coste.

Se llama explosión de cardinalidad y es la forma número uno de tumbar un sistema de métricas —a veces junto con el resto del clúster.

La regla mnemotécnica:

Los identificadores van en los logs y en las trazas. En las métricas van solo categorías con un número pequeño y conocido de valores.

Cuando necesites investigar un caso concreto, el camino correcto es: la métrica te dice que hay un problema y dónde; el log y la traza te dicen cuál. Nunca al revés.

Cuidado también con el 404 de rutas inexistentes: si registraras req.path sin coincidencia de ruta, cualquiera podría hacer explotar tu cardinalidad pidiendo URLs aleatorias. Por eso el middleware del apartado 12 agrupa bajo 'desconocida'.

Cuando una petición atraviesa varios servicios, los logs de cada uno cuentan un trozo de la historia. Una traza los cose.

El estándar de propagación es W3C Trace Context, con la cabecera traceparent:

• El trace-id es el mismo en toda la traza: es lo que une los servicios.
• El span-id identifica la operación actual; el siguiente servicio lo usará como padre.
• Los flags indican, entre otras cosas, si esta traza está muestreada.

OpenTelemetry es el estándar de instrumentación (API, SDK y protocolo) que se ha impuesto en el sector; su principal ventaja es que desacopla la instrumentación del backend: instrumentas una vez y puedes enviar a Jaeger, Tempo, Datadog o lo que uses después.

Las instrumentaciones automáticas cubren HTTP entrante y saliente, Express, gRPC y los clientes de base de datos habituales, así que la mayor parte de la traza aparece sin escribir código. Los spans manuales se añaden solo donde hay lógica de negocio que quieres ver.

Muestreo. Trazar el 100 % del tráfico es caro en red, almacenamiento y CPU. Lo habitual es un muestreo bajo (1–10 %) con dos excepciones: siempre se conservan las trazas de peticiones con error y las lentas, que son justo las que interesan.

Vista como árbol de spans, con la duración de cada uno:

Lo que se ve de un vistazo y que ninguna otra herramienta te habría dado:

• El gRPC de inventario consume el 70 % del tiempo. Optimizar la consulta SQL, que suma 13 ms, sería trabajar en el sitio equivocado.
• El webhook es asíncrono y no bloquea la respuesta. Si estuviera dentro del camino crítico, el 201 tardaría 188 ms.
• La transacción está bien acotada: tres escrituras seguidas, sin llamadas de red dentro, que es exactamente lo que se buscaba en 03-05. Una llamada gRPC dentro de la transacción mantendría el bloqueo de la base de datos durante 48 ms.

Un span manual, cuando la instrumentación automática no llega:

Una única /salud mezcla dos preguntas distintas, y confundirlas provoca incidentes en el despliegue.

Tres decisiones que evitan incidentes clásicos:

Liveness no comprueba la base de datos. Si lo hiciera y la base de datos cayera, el orquestador reiniciaría todas las instancias en bucle, añadiendo una tormenta de arranques a un incidente que ya existía.

Redis es «degradado», no fatal. Es coherente con las decisiones de 04-04 (fail-open) y 04-06 (la caché nunca es dependencia dura).

Readiness devuelve 503, no 500. Es «no ahora», no «estoy roto», y encaja con el servicio_no_disponible del catálogo. Durante el apagado ordenado de 03-07, lo correcto es empezar devolviendo 503 en readiness y seguir atendiendo las peticiones en curso: así el balanceador deja de mandar tráfico nuevo antes de que el proceso muera, y no se pierde ninguna petición. Ese detalle es el que hace posible un despliegue sin errores visibles, y volveremos sobre él en 05-05.

La regla: alerta sobre síntomas que afectan a los usuarios, no sobre causas que quizá no afecten a nadie.

Una CPU al 90 % con la latencia dentro del presupuesto no es un problema: es un servidor bien aprovechado. Despertar a alguien por eso es la forma más rápida de que las alertas dejen de mirarse.

• SLI (indicador): lo que mides. «Proporción de peticiones con estado < 500».
• SLO (objetivo): el umbral que te comprometes a cumplir. «99,9 % en 30 días».
• Presupuesto de error: lo que te permites fallar. Con un 99,9 %, es el 0,1 % del mes: unos 43 minutos.

Los de Tienda Aroma:

El presupuesto de error convierte una discusión de opiniones en una regla: si queda presupuesto, se despliegan funcionalidades nuevas; si se ha agotado, se dedica el tiempo a fiabilidad. Ya no hay que negociar «¿arreglamos esto o sacamos aquello?»: lo decide el dato.

Y la alerta correcta no es sobre el valor instantáneo, sino sobre la velocidad de consumo del presupuesto (burn rate): «a este ritmo, el presupuesto del mes se agota en dos horas». Eso distingue un pico irrelevante de un problema real.

Cada alerta debe cumplir cuatro condiciones, y si falla alguna hay que borrarla: es accionable (hay algo concreto que hacer), es urgente (no puede esperar a mañana), está documentada (un runbook con los primeros pasos) y no es ruidosa (si salta a diario, o es un problema real que hay que arreglar o es una alerta que sobra).

Seis gráficos. Ni uno más, porque un panel con cuarenta gráficos no lo mira nadie:

Los gráficos 4 y 5 son los que distinguen un panel útil de uno decorativo. El 4 detecta el fallo que ninguna métrica técnica ve: todo responde 200 y sin embargo nadie compra. El 5 es la comprobación directa de que el trabajo de 04-04 no se ha vuelto en tu contra.

El día del lanzamiento, además: ten a mano la consulta de logs filtrada por estado >= 500 ordenada por hora, y el enlace a las trazas de las peticiones más lentas. Es lo que convierte «algo va mal» en «el gRPC de inventario está tardando 2 s» en menos de un minuto.

Dos consejos al elegir, sin entrar en instalaciones:

Empieza por lo gestionado. Operar Prometheus, Loki y Jaeger es un trabajo a tiempo parcial. Para un proyecto como Tienda Aroma, un servicio gestionado cuesta menos que el tiempo de mantenerlo.

Instrumenta con OpenTelemetry pase lo que pase. Es lo único que te permite cambiar de proveedor sin volver a tocar el código.

Al empezar el módulo tenías una API correcta. Esto es lo que se ha endurecido:

La cadena de src/app.js ha pasado de 8 pasos a 16, y cada uno responde a un problema concreto que ahora sabes nombrar. El catálogo de errores creció con precondicion_requerida, y el de ámbitos apareció con OAuth. Y, sobre todo, la API ha dejado de ser una caja negra: cuando algo falle, lo sabrás antes que tus clientes y podrás averiguar qué fue.

Registrar la URI completa en lugar de la plantilla. Impide agrupar en los logs y hace explotar la cardinalidad en las métricas.

Registrar el cuerpo de la petición «para depurar». Es la vía más rápida para meter contraseñas y datos personales en un sistema con retención larga.

Marcar los 4xx como error. Genera ruido, y el ruido hace que las alertas dejen de mirarse.

Usar identificadores como etiquetas de métrica. clienteId o pedidoId revientan el sistema de métricas.

Poner la comprobación de la base de datos en liveness. Convierte una caída de la base de datos en un bucle de reinicios de toda la flota.

Dejar /metricas público. Expone rutas internas, versiones y volumen de negocio.

Alertar sobre CPU y memoria. Son causas, no síntomas. Alerta sobre latencia, errores y métricas de negocio.

Mirar la media en lugar de los percentiles. Ya lo vimos en 04-06 y sigue siendo el error de medición más frecuente.

Registrar el logger sin serializadores. pino-http incluye por defecto todas las cabeceras, incluida Authorization.

Consejo: pon el trazaId en los mensajes de error de la SPA. Convierte «no me funciona» en una investigación de dos minutos.

Consejo: instrumenta el negocio, no solo la técnica. «Pedidos por minuto» detecta incidentes que ninguna métrica de infraestructura ve.

Consejo: revisa tus alertas cada trimestre. Borra las que nunca han sido accionables. Un sistema de alertas con ruido es peor que no tener ninguno.

Consejo: antes de un incidente, escribe el runbook. A las tres de la mañana nadie improvisa bien.

Este código se ha propuesto para instrumentar el endpoint de pago. Encuentra al menos cinco problemas y corrígelos.

Tienda Aroma añade la suscripción mensual de café. Diseña las métricas para observarla: nombre, tipo, etiquetas (con su cardinalidad estimada) y qué pregunta responde cada una. Incluye al menos una métrica de negocio y una alerta útil expresada en palabras.

A las 10:15 salta la alerta «tasa de 5xx > 1 % en POST /v1/pedidos». Describe, paso a paso, cómo usarías los tres pilares para llegar a la causa, indicando qué buscas en cada uno y qué conclusión sacarías de cada resultado posible.

Solución 1

Problemas:

1. console.log en lugar del logger. Sin estructura, sin nivel, sin trazaId, y no llega al sistema de logs con formato.
2. Registra el cuerpo completo. El cuerpo de un pago puede contener datos de tarjeta. Es un fallo grave de seguridad y de RGPD.
3. Cardinalidad explosiva en la métrica. ruta con el identificador real y una etiqueta cliente con el clienteId: una serie por cada pedido y por cada cliente.
4. Solo cuenta los éxitos. El inc() está dentro del try tras la operación, así que los errores no se cuentan y la tasa de error es siempre cero.
5. No mide la latencia como métrica, solo la imprime. No hay histograma ni percentiles.
6. Devuelve error.message al cliente. Filtra el interior del sistema: rompe lo establecido en 03-07 y 04-02.
7. No usa el manejador de errores central. El formato del error no cumple el contrato (codigo, mensaje, detalles, trazaId).
8. Falta asincrono(): un rechazo no capturado dejaría la petición colgada. (En este caso el try/catch lo tapa, pero el convenio del proyecto es asincrono.)

Corrección:

Solución 2

Métrica de negocio principal: aroma_suscripciones_activas. Es la que refleja el valor real de la funcionalidad; si cae, hay un problema aunque toda la técnica esté verde.

Etiquetas descartadas por cardinalidad: clienteId (millones), suscripcionId (ilimitados), cafeId (crece con el catálogo, y con miles de referencias sería problemático).

Alerta útil: «la proporción de cobros de suscripción con resultado fallo supera el 5 % en una ventana de 30 minutos». Cumple las cuatro condiciones: es accionable (revisar la pasarela y los métodos de pago caducados), urgente (cada hora son ingresos perdidos y clientes molestos), documentable en un runbook, y no ruidosa, porque un porcentaje pequeño de fallos es normal y el umbral está por encima.

Alerta complementaria: «el proceso mensual de generación de envíos no ha registrado ningún incremento en aroma_suscripciones_envios_generados_total durante su ventana de ejecución». Detecta el fallo silencioso más peligroso de un proceso programado: que sencillamente no se ejecute.

Solución 3

Paso 1 — Métricas: acotar el problema (2 minutos).

• Gráfico de tasa de error por ruta: ¿es solo POST /v1/pedidos o también otros? Si son todos, apunta a algo transversal (base de datos, despliegue). Si es solo ese, a su lógica o a una dependencia suya.
• ¿Cuándo empezó exactamente? Correlacionar con el historial de despliegues. Un salto brusco a una hora exacta suele ser un despliegue o un cambio de configuración; una subida progresiva apunta a agotamiento de recursos o crecimiento de datos.
• Latencia: si el p99 subió antes que los errores, probablemente son timeouts. Si los errores aparecieron sin cambio de latencia, es un fallo lógico (una excepción).
• aroma_pedidos_creados_total: ¿ha caído? Confirma el impacto real en el negocio y da urgencia.
• Saturación: memoria, event loop, pool de conexiones. Descarta o confirma agotamiento de recursos.

Paso 2 — Trazas: localizar dónde se rompe (3 minutos).

• Filtrar trazas de POST /v1/pedidos con error en los últimos 15 minutos.
• Mirar el árbol de spans: ¿en qué span termina la traza? Resultados posibles y su lectura:
  • Se corta en grpc.inventario.ReservarStock → el servicio de inventario falla o va lento.
  • Se corta en db.transaccion → problema de base de datos: bloqueo, disco, migración a medias.
  • Termina rápido sin llegar a las dependencias → excepción en la validación o en la lógica.
  • Todos los spans son normales pero el total es enorme → contención o pausas del recolector de basura.
• Comparar con una traza correcta de antes del incidente: la diferencia salta a la vista.

Paso 3 — Logs: obtener el detalle (2 minutos).

• Tomar el trazaId de una traza fallida y buscar todas sus líneas.
• Leer la línea de nivel error: mensaje, tipo de excepción y stack completo.
• Comprobar el patrón: ¿fallan todos los pedidos o solo algunos? Filtrar por clienteOauth (¿solo la SPA? ¿solo CataBox?), por clienteId (¿un cliente concreto con datos raros?), por número de líneas del pedido.
• Buscar warn en los minutos previos: consultas lentas, Redis caído, 429. A menudo la causa raíz aparece ahí antes que el error.

Conclusión y acción. Con los tres pasos tienes: qué falla (la métrica), dónde (la traza) y por qué (el log). Si la causa es un despliegue reciente, se revierte antes de seguir investigando —restaurar el servicio primero, entender después—. Si es una dependencia externa, se activa el circuit breaker de 04-04 para degradar en lugar de fallar. Y el incidente se cierra con dos cosas: una prueba de regresión que lo reproduzca (03-08) y, si la alerta llegó tarde, una alerta nueva o un ajuste del umbral.

La observabilidad es la capa que convierte un sistema que funciona en un sistema que se puede operar. Has sustituido por fin el console.log de la posición 5 por pino con logs estructurados en JSON, con un logger hijo por petición que arrastra el trazaId que llevamos emitiendo desde 03-02, la ruta registrada como plantilla y no como URI, niveles bien asignados —los 4xx no son errores—, serializadores en lista blanca y redacción automática de contraseñas, tokens y datos personales, con su prueba y con la política de retención que exige el RGPD. Has visto cómo se correlaciona Aroma-Traza-Id de extremo a extremo, desde la SPA hasta el gRPC de inventario y los webhooks a RápidoEnvíos, y cómo se cierra el círculo que abrió 03-07: al equipo, el stack completo; al cliente, error_interno y una referencia con la que soporte encuentra todo en diez segundos. Has instrumentado la API con prom-client siguiendo las cuatro señales de oro y el método RED, con histogramas cuyos cubos salen del presupuesto de latencia de 04-06, métricas de negocio —pedidos creados, stock agotado, 429 emitidos, aciertos de caché— y /metricas protegido y fuera de /v1, sabiendo por qué etiquetar con ped_5001 revienta el sistema. Conoces las trazas distribuidas, traceparent de W3C y OpenTelemetry, y sabes leer un árbol de spans de POST /v1/pedidos para descubrir que el 70 % del tiempo estaba donde no mirabas. Y has separado liveness de readiness, definido SLO con presupuesto de error, y elegido qué alertar —síntomas, nunca CPU— y qué mirar el día del lanzamiento.

Con esto se cierra el módulo 4. La API de Tienda Aroma ya no es solo correcta: tiene criterio de diseño con antipatrones identificados y linting del contrato; conoce sus amenazas y las defiende con helmet, gestión de secretos y controles de RGPD; delega el acceso a terceros con OAuth 2.0 y OpenID Connect sin ver una sola contraseña; se protege del abuso con límites por nivel, 429 y Retry-After; deja entrar a la SPA y al panel sin abrir la puerta a nadie más; responde 304 en lugar de repetirse y cierra la concurrencia optimista con If-Match y el 412; y cuenta lo que le pasa en logs, métricas y trazas correlacionadas. Es una API lista para producción.

Lo que falta ya no es la API: son las herramientas que la rodean y el trabajo de equipo que la sostiene. En el módulo 5, Herramientas y Frameworks, dejaremos de escribir código de servidor para trabajar sobre él: Postman para explorar, probar y compartir colecciones ejecutables (05-01); Swagger y OpenAPI para convertir ese openapi.yaml que arrastramos desde 02-08 en documentación viva, generación de clientes y validación (05-02); un recorrido comparado por los frameworks populares —Fastify, NestJS, Django REST, Spring Boot, ASP.NET Core— para saber qué se gana y qué se pierde al elegir cada uno (05-03); contratos, mocks y pruebas automatizadas para que consumidor y proveedor no se rompan mutuamente (05-04); integración continua y despliegue, donde Spectral, npm audit, las pruebas y el readiness que acabamos de escribir se convierten en una tubería que despliega sin cortes (05-05); y los API gateways y portales de desarrollador, donde varios de los mecanismos de este módulo —rate limiting, autenticación, caché, métricas— reaparecen resueltos una capa por encima (05-06).