En 01-04, al enumerar las seis restricciones de REST, dijimos que cacheable era una de ellas y que volveríamos. Ha llegado el momento. La API de Tienda Aroma responde GET /v1/cafes en 40 milisegundos, lo cual está muy bien, salvo por un detalle: la SPA pide ese catálogo cada vez que un usuario abre la página de inicio, y el catálogo cambia una vez al día. Millones de peticiones idénticas, con la misma respuesta, consumiendo base de datos, CPU y ancho de banda para no aportar absolutamente nada nuevo.

La petición más rápida es la que no se hace. La segunda más rápida es la que se responde con un 304 Not Modified de 150 bytes. Esta lección convierte la restricción teórica en cabeceras concretas y en código dentro del proyecto: src/middleware/cache.js, Cache-Control calibrado recurso a recurso, ETag con peticiones condicionales, y el reencuentro que llevamos anunciando desde 03-05, cuando If-Match y el 412 cierren el círculo de la concurrencia optimista. Después iremos más allá de la caché —compresión, N+1, respuestas parciales, trabajo asíncrono— y terminaremos con lo que debería ir primero: medir antes de optimizar.

1. Los niveles de caché
2. Cache-Control a fondo
3. La política de caché de Tienda Aroma
4. Validación condicional: ETag y Last-Modified
5. El flujo completo del 304
6. If-Match y el 412: se cierra el círculo con la concurrencia optimista
7. Implementación: src/middleware/cache.js
8. Vary, negociación de contenido y CORS
9. Invalidación: el problema difícil
10. Caché de servidor con Redis y cache-aside
11. Stampede y el bloqueo
12. Compresión
13. Conexiones, HTTP/2 y latencia de red
14. Base de datos: índices, N+1 y consultas lentas
15. Respuestas parciales y paginación como medida de rendimiento
16. Trabajo asíncrono con 202
17. Medir antes de optimizar

Entre el usuario y los datos hay varias oportunidades de no hacer trabajo. Cada nivel que acierta ahorra todo lo que hay a su derecha.

Dos conceptos que hay que distinguir bien porque de ellos depende una decisión de seguridad:

• Caché privada: la del navegador. Guarda respuestas de un usuario.
• Caché compartida: CDN, proxy corporativo. Guarda respuestas que sirve a muchos usuarios.

De ahí sale la regla más importante de toda la lección: cualquier respuesta que dependa de quién pregunta debe llevar Cache-Control: private como mínimo. Si GET /v1/pedidos de Marta acaba en una CDN sin esa directiva, la siguiente persona que pida /v1/pedidos podría recibir los pedidos de Marta. Es una fuga de datos causada por una cabecera ausente, y ha ocurrido en producción en empresas grandes más de una vez.

Es la cabecera que gobierna todo. Sus directivas, agrupadas por lo que hacen:

no-cache no significa «no cachear». Es el error de lectura más repetido de HTTP. no-cache significa «guárdalo, pero pregúntame antes de usarlo». La que impide guardar es no-store. La diferencia importa mucho: con no-cache una respuesta que no ha cambiado se resuelve con un 304 de 150 bytes; con no-store se transfiere entera cada vez.

stale-while-revalidate es la directiva más infravalorada. Con max-age=60, stale-while-revalidate=300, durante los primeros 60 segundos se sirve de caché sin más; entre el segundo 60 y el 360, se sirve la copia caducada de inmediato y se refresca en segundo plano. El usuario nunca espera. Para un catálogo que cambia una vez al día, es exactamente el comportamiento deseable.

stale-if-error es resiliencia gratis: si tu API devuelve 503, la CDN sigue sirviendo la última copia buena en lugar de propagar el error. Combinada con lo que vimos en 04-04, convierte una caída parcial en una degradación invisible.

Cuatro decisiones que merecen justificación:

no-cache en /v1/pedidos, no no-store. Los pedidos de Marta cambian poco entre visitas. Con no-cache, el navegador guarda la copia y en la siguiente visita manda un If-None-Match; si nada ha cambiado recibe un 304 sin cuerpo. Se ahorra todo el tráfico manteniendo la garantía de frescura, que es lo mejor de los dos mundos. Y private impide que una CDN lo guarde.

no-store en POST /v1/sesiones. La respuesta contiene el token de acceso. Que quede en el disco del navegador o en un proxy es exactamente lo que no queremos.

no-store en los errores. Un 429 cacheado durante cinco minutos convierte un límite de un minuto en cinco. Un 503 cacheado sobrevive a la recuperación del servicio.

Un año e immutable en las imágenes. Solo funciona porque el nombre del fichero contiene un hash del contenido (caf_001-a3f9.webp): si la imagen cambia, cambia la URL, así que la copia antigua nunca es incorrecta. Es el patrón de fingerprinting, y es la única forma segura de usar caducidades tan largas.

Implementado como middleware parametrizable:

max-age responde a «¿puedo usar mi copia sin preguntar?». Cuando caduca, la pregunta pasa a ser «¿ha cambiado?», y ahí entran los validadores.

Un identificador opaco de la versión de un recurso.

Un ETag débil sirve para el 304 pero no para If-Match en escrituras ni para peticiones por rangos, precisamente porque no garantiza igualdad exacta. Como Tienda Aroma va a usar If-Match para la concurrencia optimista, necesitamos ETags fuertes.

Dos formas de generarlo:

Tienda Aroma usa las dos: el campo version de 03-05 para recursos individuales que lo tienen, y el hash para colecciones y para todo lo demás.

Las comillas no son decorativas: forman parte de la sintaxis de la cabecera. Un ETag: a3f9 sin comillas es inválido y muchos intermediarios lo ignoran, con lo que la caché deja de funcionar sin dar ningún error.

Una fecha HTTP:

Es más débil que el ETag por dos razones: tiene resolución de un segundo —dos cambios en el mismo segundo son indistinguibles— y muchos recursos no tienen una fecha de modificación fiable.

Tienda Aroma emite ambos cuando dispone de fechaActualizacion, pero el ETag es el mecanismo principal.

Primera petición. El cliente no tiene nada:

Dentro de los 300 segundos: el navegador sirve su copia sin preguntar. Cero peticiones, cero latencia.

Pasados los 300 segundos: la copia está caducada, pero el navegador tiene el validador y pregunta:

Si nada ha cambiado:

Sin cuerpo. 284 bytes se convierten en unos 150 de cabeceras, y el navegador renueva la frescura de su copia otros 300 segundos.

Si el café cambió (version pasó a 8):

Tres detalles del 304 que se equivocan a menudo:

• No lleva cuerpo. Enviar uno es un error de protocolo.
• Sí lleva las cabeceras de caché (Cache-Control, ETag, Vary): son las que renuevan la validez de la copia guardada.
• If-None-Match admite varios ETags separados por comas, y el comodín * que significa «si existe cualquier representación».

Aquí está el reencuentro que anunciamos en 03-05. If-None-Match sirve para leer; If-Match sirve para escribir de forma segura.

Nadie ha visto un error. El precio 15,20 nunca existió.

Si la versión actual ya no es la 7:

El ETag: "v8" en la respuesta de error es un detalle de diseño valioso: le dice al cliente cuál es la versión actual, así que puede releer, mostrar el conflicto al usuario y reintentar sin una petición extra.

En 03-05 implementamos la concurrencia optimista con version dentro del JSON. Funciona, pero If-Match es mejor por cinco razones:

La última fila es la clave conceptual: el cliente ya recibió el ETag al leer el recurso. No necesita entender qué es version, ni extraerlo del cuerpo: devuelve la etiqueta opaca que le dieron. Eso es exactamente el diseño de HTTP.

Y hay una decisión de contrato importante: exigir If-Match o no.

Tienda Aroma la exige en PUT /v1/cafes/{id} y en PATCH /v1/pedidos/{id}, porque un precio o un stock mal pisados tienen consecuencias comerciales reales. Eso obliga a añadir un código nuevo al catálogo: precondicion_requerida (428). Lo anotamos explícitamente, como exige la regla del proyecto —el catálogo solo crece—, y hay que documentarlo en openapi.yaml.

El comentario del medio es el punto fino: comprobar la versión en el servicio no basta; entre la lectura y la escritura hay una ventana. La garantía real la da el WHERE version = ? del UPDATE, que es atómico. If-Match aporta la semántica HTTP correcta y el error temprano; la corrección la sigue dando la base de datos.

Y Accept-Patch, que ya emitíamos desde 02-05, acompaña a esto: dice al cliente qué formato de parche acepta el recurso, igual que ETag le dice qué versión tiene.

Falta la pieza que responde el 304 automáticamente. La estrategia: envolver res.json para calcular el ETag justo antes de enviar y comparar con If-None-Match.

Por qué etagCondicional en la posición 10, justo antes de las rutas. Tiene que envolver res.json antes de que ningún controlador lo llame, y a la vez estar después de todo lo que pueda responder por su cuenta (rate limiting, parser), porque a esas respuestas no queremos ponerles ETag. Y por qué compression en la 7, antes: la compresión debe envolver la escritura de la respuesta lo antes posible, y además no debe intentar comprimir un 304 que no tiene cuerpo.

Una nota práctica: Express trae su propio ETag automático (app.set('etag', ...)), pero es débil por defecto, lo que lo inutiliza para If-Match. Nuestro middleware lo sustituye con ETags fuertes y con control explícito sobre cuándo se emiten.

Vary declara de qué cabeceras de la petición depende la respuesta. Es lo que impide que una caché sirva la respuesta equivocada.

El caso de Authorization merece explicación porque parece la respuesta obvia y no lo es. Poner Vary: Authorization haría que la caché guardara una entrada por cada token distinto: como los tokens cambian cada 15 minutos, la tasa de acierto sería prácticamente cero y el consumo de memoria de la CDN, enorme. La forma correcta de proteger contenido personalizado es Cache-Control: private, que impide directamente que una caché compartida lo guarde.

Y la advertencia de coste: cada cabecera en Vary multiplica las variantes almacenadas. Vary: Accept, Accept-Language, Origin con 2 tipos, 3 idiomas y 3 orígenes son 18 copias del mismo recurso. Declara solo lo que realmente cambia la respuesta.

«Solo hay dos cosas difíciles en informática: la invalidación de caché y poner nombres a las cosas.» — Phil Karlton

La dificultad es real: has distribuido copias de tus datos por navegadores y CDN de todo el mundo, y ahora el precio de caf_001 ha cambiado.

La caché del navegador no se puede purgar. Una vez enviado max-age=3600, ese navegador servirá la copia durante una hora y no hay nada que hacer. Es la razón de que los TTL para el navegador sean cortos (60 s) y los de la CDN largos (300 s con s-maxage): la CDN sí se puede purgar.

Las etiquetas de purga (surrogate keys) son el mecanismo que hace esto manejable. Cada respuesta declara a qué grupos pertenece:

Y al cambiar caf_001 se purga por etiqueta, en vez de tener que enumerar las docenas de URLs afectadas (la ficha, la lista, la lista filtrada por origen, la ordenada por precio...). Sin etiquetas, la invalidación de colecciones es prácticamente imposible de hacer bien.

Por qué la invalidación por evento encaja con los webhooks. Tienda Aroma ya emite eventos firmados hacia RápidoEnvíos (pedido.pagado, pedido.enviado). El mismo mecanismo sirve para la caché: cuando el servicio de catálogo cambia un precio, publica cafe.actualizado y quien esté suscrito —la CDN, otra instancia, el panel— purga lo suyo. La ventaja es el desacoplamiento: el servicio que escribe no necesita conocer todas las cachés que existen, solo anunciar que algo cambió.

La caché HTTP evita peticiones. La caché de servidor evita consultas a la base de datos para las peticiones que sí llegan.

Qué merece la pena cachear en Tienda Aroma:

Las dos últimas filas son tan importantes como las primeras: saber qué no cachear evita incidentes. Cachear el stock 60 segundos significa vender café que no existe.

El patrón cache-aside (o lazy loading):

Cuatro reglas para no meterse en problemas:

1. Cachea el resultado ya mapeado, no la fila cruda. Así el objeto en Redis no contiene columnas internas: si un día alguien lo vuelca para depurar, no filtra precio_centimos ni activo.
2. La caché nunca es una dependencia dura. Si Redis cae, la API funciona más lenta, no falla.
3. Espacio de nombres en las claves (aroma:cache:), separado del aroma:rl: del rate limiting de 04-04.
4. Invalida al escribir, en la misma operación que modifica el dato.

Un aviso importante: no cachees objetos de error ni excepciones. En el ejemplo, si el café no existe se lanza antes de guardar nada; si se cacheara el null, un café recién creado tardaría cinco minutos en aparecer.

Escenario: caf_001 es el café más pedido y su entrada de caché caduca a las 12:00:00. En ese instante hay 500 peticiones en vuelo. Las 500 fallan la caché, las 500 consultan la base de datos y las 500 escriben el mismo valor.

Eso es la estampida de caché (cache stampede o thundering herd), y es especialmente cruel porque ocurre justo en los recursos más populares, es decir, en el peor momento posible.

Tres defensas, de menos a más eficaz:

TTL con jitter. En lugar de 300 segundos exactos, un valor aleatorio entre 270 y 330. Reparte las caducidades y evita que miles de claves expiren a la vez. Es una línea de código:

Bloqueo (lock). Solo un proceso recalcula; el resto espera brevemente y reintenta la caché:

Refresco anticipado. Guardar junto al valor su instante de caducidad y refrescarlo antes de que expire, de forma probabilística. Nunca hay un momento en que la clave no exista. Es lo que hace stale-while-revalidate en la caché HTTP, aplicado al servidor.

El ahorro en JSON es notable porque es texto con mucha repetición de claves:

Cuándo no comprimir:

• Respuestas pequeñas (por debajo de ~1 kB): la sobrecarga supera al ahorro.
• Contenido ya comprimido: imágenes, vídeo, PDF, ZIP.
• Cuando la CPU es el cuello de botella y la red va sobrada.
• Históricamente, respuestas con secretos junto a datos controlados por el atacante, por los ataques BREACH/CRIME. Con Authorization: Bearer en vez de cookies el riesgo práctico es mucho menor, pero conviene conocerlo.

Brotli comprime mejor que gzip y lo soportan todos los navegadores modernos; la mayoría de las CDN lo aplican por sí solas. Si tienes CDN, lo habitual es dejar que ella comprima y ahorrar esa CPU en tu proceso.

Recuperando 01-03 con perspectiva de rendimiento:

Recordatorio de 04-04: keepAliveTimeout de Node debe ser mayor que el del balanceador, o aparecerán 502 esporádicos imposibles de reproducir.

Y la perspectiva que ordena las prioridades: en una petición móvil típica, la latencia de red domina sobre todo lo demás. Si tu API responde en 40 ms y el usuario está a 150 ms de distancia, optimizar la consulta SQL para bajar a 30 ms mejora el total un 5 %. Reducir de cinco peticiones a una (04-01) o servir desde una CDN mejora mucho más. La optimización más rentable casi nunca está en el servidor.

Índices. Cada filtro del contrato necesita el suyo:

El orden de las columnas en un índice compuesto importa: (cliente_id, fecha_creacion) sirve para filtrar por cliente y ordenar por fecha, pero no para ordenar por fecha sin filtrar por cliente. Y los índices no son gratis: aceleran las lecturas y ralentizan las escrituras, porque hay que mantenerlos.

Cómo verificar que se usan:

El N+1, ahora en la base de datos (en 04-01 lo vimos sobre HTTP):

Nota de seguridad sobre el IN: los marcadores ? se generan a partir del número de elementos, y los valores van como parámetros. Nunca se interpolan los ids en el SQL (04-02). Y hay que acotar el tamaño de la lista, porque los motores tienen un límite de parámetros; con limite máximo 100 estamos muy por debajo.

Consultas lentas. Un registro sencillo detecta lo que las pruebas nunca ven:

El comentario señala una decisión de RGPD: la plantilla SQL se registra, los valores no.

Dos mecanismos del módulo 2 que ahora se leen como optimizaciones de primer orden.

campos (02-05): si la lista de Aroma Móvil solo muestra nombre, precio y tueste, pedir el objeto entero desperdicia ancho de banda y serialización.

Paginación (02-06): además de ser obligatoria por diseño (04-01), es la defensa más efectiva contra la degradación con el crecimiento. Y el cursor de /pedidos no es un capricho: con desplazamiento=100000, el motor tiene que localizar y descartar 100.000 filas antes de devolver 20. Con cursor, salta directamente por índice.

Algunas operaciones no caben en el ciclo de una petición. Generar la factura PDF de un pedido con veinte líneas, o la exportación de datos del ejercicio de 04-02, tardan segundos.

Mantener la conexión abierta es mala idea: agota los procesos, choca con los timeouts del balanceador y hace que un fallo de red obligue a repetir todo el trabajo. El patrón correcto:

El cliente consulta el recurso de tarea:

Y al terminar:

Cuatro detalles de diseño:

• 202 significa «aceptado, aún no hecho», y es distinto de 201 («creado»). El árbol de decisión de 02-04 lo contemplaba.
• La tarea es un recurso, con su URI, su representación y sus _links. No es un mecanismo aparte.
• Retry-After en la consulta evita que el cliente pregunte cada 50 ms. Es el mismo mecanismo de 04-04, aplicado a algo que no es un error.
• 303 See Other al terminar redirige al recurso final. Y el código operacion_en_curso del catálogo cubre el caso de pedir la factura mientras se está generando.

Para el panel interno, en lugar de sondear se usa SSE, que ya forma parte de la arquitectura de Tienda Aroma: el servidor empuja el cambio de estado cuando ocurre.

Todo lo anterior es inútil —o contraproducente— si se aplica a ciegas. El orden correcto es siempre: medir, encontrar el cuello de botella real, arreglar eso, volver a medir.

Diez peticiones: nueve de 20 ms y una de 2.000 ms.

La media es un promedio de dos poblaciones distintas y no describe a ninguna. Los percentiles son lo que hay que mirar, y el p99 es el más importante, porque una página que hace 10 peticiones tiene ~10 % de probabilidad de que al menos una caiga en el p99. Tu p99 es la experiencia habitual de tus usuarios más activos.

Se decide antes de optimizar, y se convierte en el criterio para saber cuándo parar:

El login es deliberadamente el más lento: bcrypt con coste 12 tarda ~100 ms a propósito (03-06). Ese no es un problema de rendimiento que haya que arreglar, es una defensa funcionando. Sin el presupuesto escrito, alguien acabará «optimizándolo» bajando el coste de bcrypt.

Salida típica:

Cómo leerlo sin engañarse:

• Mira el p99 (columna 99 %), no la media.
• Compara siempre contra una línea base tomada antes del cambio. Un número absoluto solo no dice nada.
• Una sola máquina no es producción: no hay latencia de red real, ni CDN, ni otras instancias, ni datos de verdad.
• Con pocos datos, todo va rápido. Prueba con un volumen realista: una tabla de 100 filas cabe en memoria y esconde la falta de índices.
• Vigila la CPU y la memoria durante la prueba. Si la CPU está al 100 %, el cuello es tuyo; si está al 20 % y la latencia sube, el cuello está en la base de datos o en un tercero.

1. Mide y localiza el endpoint lento real, con datos de producción.
2. ¿Se puede evitar la petición? Caché HTTP. Es la mayor ganancia posible.
3. ¿Se puede reducir el número de peticiones? expandir (04-01).
4. ¿Se puede evitar la consulta? Caché de servidor.
5. ¿Se puede hacer la consulta más barata? Índices, N+1, campos.
6. ¿Se puede hacer después? 202 y trabajo asíncrono.
7. Vuelve a medir y comprueba contra el presupuesto.

Y una advertencia final: la caché añade complejidad y una clase nueva de bugs —datos obsoletos, invalidación incompleta, incoherencias entre niveles—. Si un endpoint responde en 15 ms y se llama diez veces al día, cachearlo no aporta nada y sí añade una forma más de fallar.

Creer que no-cache significa «no cachear». Significa «revalida siempre». La que impide guardar es no-store.

Olvidar private en respuestas personalizadas. Una CDN puede servir los pedidos de un usuario a otro. Es la fuga de datos más grave de esta lección.

Cachear respuestas de error. Un 429 cacheado cinco minutos convierte un bloqueo de un minuto en cinco.

Usar ETags débiles para If-Match. No garantizan igualdad exacta y el estándar no lo permite. El ETag automático de Express es débil.

Devolver cuerpo en un 304. Es un error de protocolo; además anula el ahorro.

Olvidar Vary. Con negociación de contenido o CORS, provoca respuestas cruzadas intermitentes e imposibles de reproducir.

Cachear el stock. Provoca sobreventa. Hay datos que deben ser exactos siempre.

Poner TTL largos en el navegador. No se pueden purgar. Cortos en el navegador, largos en la CDN con s-maxage.

Optimizar sin medir. La mayoría del tiempo se pierde donde nadie mira, y el trabajo se dedica donde ya era rápido.

Consejo: empieza por el catálogo. Es el 80 % del tráfico y el más cacheable. Bien resuelto, resuelve casi todo.

Consejo: haz que la caché sea observable. Sin métricas de aciertos y fallos no sabes si funciona. Es tema de 04-07.

Consejo: prueba el 304 explícitamente. Es fácil que el middleware deje de funcionar en un refactor y nadie se entere: solo se nota en la factura de ancho de banda.

Para cada recurso, decide Cache-Control completo y si emitirías ETag. Justifica cada elección:

1. GET /v1/cafes?origen=Etiopía — catálogo filtrado, público.
2. GET /v1/clientes/cli_842/preferencias — preferencias del usuario autenticado.
3. GET /v1/cafes/caf_001/imagen — imagen cuyo nombre incluye un hash.
4. POST /v1/sesiones — devuelve tokens.
5. GET /v1/pedidos/ped_5001 — pedido del propio cliente, consultado a menudo.
6. GET /v1/cafes/caf_001/resenas?ordenar=-fechaCreacion — reseñas públicas.

Implementa el borrado condicional de una reseña: DELETE /v1/resenas/{id} debe exigir If-Match, devolver 204 si la versión coincide, 412 conflicto_version si no, 428 precondicion_requerida si falta la cabecera y 404 si no existe. Escribe la ruta, el servicio y una prueba de integración de los cuatro casos.

GET /v1/pedidos?limite=20&expandir=lineas.cafe tiene un p50 de 45 ms y un p99 de 1.800 ms. La CPU del servidor está al 25 % durante la prueba de carga. Enumera al menos cuatro causas posibles, ordenadas por probabilidad, y di cómo verificarías y corregirías cada una.

Solución 1

Solución 2

Nota de diseño: el 404 se comprueba antes que el If-Match, porque no tiene sentido hablar de la versión de algo que no existe, y porque responder 412 en un recurso inexistente filtraría información sobre su existencia.

Solución 3

Que la CPU esté al 25 % descarta que el cuello sea el propio proceso Node. La distancia entre p50 y p99 (40×) apunta a algo que ocurre solo a veces, no a un coste constante.

Procedimiento: primero el registro de consultas lentas del apartado 14, que en cinco minutos distingue entre 1-2-3 (base de datos) y 5-6 (proceso). Después medir contra el presupuesto (p99 de 400 ms para escrituras; para esta lectura debería estar en el entorno de 150 ms) y parar cuando se cumpla, no antes ni después.

La restricción «cacheable» de 01-04 es ya implementación. Conoces los cuatro niveles de caché y la regla que evita la fuga más grave —private en todo lo que dependa de quién pregunta—; dominas Cache-Control directiva a directiva, incluido ese no-cache que no significa «no cachear» y ese stale-while-revalidate que elimina la espera del refresco; tienes la política de Tienda Aroma recurso a recurso, con el catálogo cacheado y /v1/pedidos revalidado siempre. Has implementado la validación condicional con ETag fuerte —del hash del cuerpo o del campo version que ya existía— y el flujo completo del 304. Y sobre todo se ha cerrado el círculo que quedó abierto en 03-05: If-Match y el 412 resuelven la actualización perdida con la semántica estándar de HTTP, funcionan con DELETE, los entienden los intermediarios y reutilizan el mismo ETag que el cliente recibió al leer; a cambio, el catálogo de errores crece con precondicion_requerida (428), que hay que documentar en openapi.yaml. En el proyecto tienes src/middleware/cache.js con cacheDe, etagCondicional y exigirIfMatch, src/servicios/cache.js con cache-aside y bloqueo, src/servicios/cache-invalidacion.js, y compression en la posición 7 con etagCondicional en la 10 de src/app.js. Más allá de la caché: compresión, keep-alive, índices, el N+1 resuelto con una consulta agrupada, campos, paginación por cursor y el 202 con recurso de tarea para la factura. Y, lo primero aunque se cuente al final, el presupuesto de latencia, los percentiles frente a la media y autocannon para medir antes de tocar nada.

Solo queda una cosa antes de cerrar el módulo, y es la que hace posible todo lo demás: saber qué está pasando. En 04-07, Observabilidad: logs, métricas y trazas, sustituiremos por fin el console.log de la posición 5 de src/app.js por logs estructurados con pino, con un logger hijo por petición que arrastra el trazaId que emitimos desde 03-02, los campos que hay que registrar siempre y los que nunca —contraseñas, tokens, datos personales— con su redacción automática. Instrumentaremos Tienda Aroma con prom-client y las cuatro señales de oro, exponiendo /metricas protegido y fuera de /v1, con la advertencia sobre la cardinalidad que revienta los sistemas de métricas. Veremos las trazas distribuidas con traceparent y OpenTelemetry sobre un POST /v1/pedidos completo —validación, SQL, gRPC de inventario y webhook—, la diferencia entre liveness y readiness en /salud, y cómo se alerta sobre síntomas y SLO en lugar de sobre la CPU. Y cerraremos el módulo con el balance de todo lo que se ha endurecido.