A 01-04, en enumerar les sis restriccions de REST, vam dir que cacheable era una d'elles i que hi tornaríem. Ha arribat el moment. L'API de la Botiga Aroma respon GET /v1/cafes en 40 mil·lisegons, cosa que està molt bé, tret d'un detall: la SPA demana aquell catàleg cada vegada que un usuari obre la pàgina d'inici, i el catàleg canvia un cop al dia. Milions de peticions idèntiques, amb la mateixa resposta, consumint base de dades, CPU i amplada de banda per no aportar absolutament res de nou.

La petició més ràpida és la que no es fa. La segona més ràpida és la que es respon amb un 304 Not Modified de 150 bytes. Aquesta lliçó converteix la restricció teòrica en capçaleres concretes i en codi dins del projecte: src/middleware/cache.js, Cache-Control calibrat recurs a recurs, ETag amb peticions condicionals, i el retrobament que portem anunciant des de 03-05, quan If-Match i el 412 tanquin el cercle de la concurrència optimista. Després anirem més enllà de la memòria cau —compressió, N+1, respostes parcials, treball asíncron— i acabarem amb el que hauria d'anar primer: mesurar abans d'optimitzar.

1. Els nivells de memòria cau
2. Cache-Control a fons
3. La política de memòria cau de la Botiga Aroma
4. Validació condicional: ETag i Last-Modified
5. El flux complet del 304
6. If-Match i el 412: es tanca el cercle amb la concurrència optimista
7. Implementació: src/middleware/cache.js
8. Vary, negociació de contingut i CORS
9. Invalidació: el problema difícil
10. Memòria cau de servidor amb Redis i cache-aside
11. Estampida i el bloqueig
12. Compressió
13. Connexions, HTTP/2 i latència de xarxa
14. Base de dades: índexs, N+1 i consultes lentes
15. Respostes parcials i paginació com a mesura de rendiment
16. Treball asíncron amb 202
17. Mesurar abans d'optimitzar

Entre l'usuari i les dades hi ha diverses oportunitats de no fer feina. Cada nivell que encerta estalvia tot el que hi ha a la seva dreta.

Dos conceptes que cal distingir bé perquè d'ells depèn una decisió de seguretat:

• Memòria cau privada: la del navegador. Desa respostes d'un usuari.
• Memòria cau compartida: CDN, proxy corporatiu. Desa respostes que serveix a molts usuaris.

D'aquí surt la regla més important de tota la lliçó: qualsevol resposta que depengui de qui pregunta ha de portar Cache-Control: private com a mínim. Si el GET /v1/comandes de la Marta acaba en una CDN sense aquella directiva, la propera persona que demani /v1/comandes podria rebre les comandes de la Marta. És una fuita de dades causada per una capçalera absent, i ha passat en producció a empreses grans més d'una vegada.

És la capçalera que ho governa tot. Les seves directives, agrupades pel que fan:

no-cache no significa «no desar a la memòria cau». És l'error de lectura més repetit d'HTTP. no-cache significa «desa-ho, però pregunta'm abans de fer-ho servir». La que impedeix desar és no-store. La diferència importa molt: amb no-cache una resposta que no ha canviat es resol amb un 304 de 150 bytes; amb no-store es transfereix sencera cada vegada.

stale-while-revalidate és la directiva més infravalorada. Amb max-age=60, stale-while-revalidate=300, durant els primers 60 segons se serveix de la memòria cau sense més; entre el segon 60 i el 360, se serveix la còpia caducada immediatament i es refresca en segon pla. L'usuari no espera mai. Per a un catàleg que canvia un cop al dia, és exactament el comportament desitjable.

stale-if-error és resiliència de franc: si la teva API retorna 503, la CDN continua servint l'última còpia bona en comptes de propagar l'error. Combinada amb el que vam veure a 04-04, converteix una caiguda parcial en una degradació invisible.

Quatre decisions que mereixen justificació:

no-cache a /v1/comandes, no no-store. Les comandes de la Marta canvien poc entre visites. Amb no-cache, el navegador desa la còpia i a la visita següent envia un If-None-Match; si res no ha canviat rep un 304 sense cos. S'estalvia tot el trànsit mantenint la garantia de frescor, que és el millor dels dos mons. I private impedeix que una CDN ho desi.

no-store a POST /v1/sessions. La resposta conté el token d'accés. Que quedi al disc del navegador o en un proxy és exactament el que no volem.

no-store als errors. Un 429 desat durant cinc minuts converteix un límit d'un minut en cinc. Un 503 desat sobreviu a la recuperació del servei.

Un any i immutable a les imatges. Només funciona perquè el nom del fitxer conté un hash del contingut (caf_001-a3f9.webp): si la imatge canvia, canvia la URL, així que la còpia antiga mai no és incorrecta. És el patró de fingerprinting, i és l'única manera segura de fer servir caducitats tan llargues.

Implementat com a middleware parametritzable:

max-age respon a «puc fer servir la meva còpia sense preguntar?». Quan caduca, la pregunta passa a ser «ha canviat?», i aquí entren els validadors.

Un identificador opac de la versió d'un recurs.

Un ETag feble serveix per al 304 però no per a If-Match en escriptures ni per a peticions per rangs, precisament perquè no garanteix igualtat exacta. Com que la Botiga Aroma farà servir If-Match per a la concurrència optimista, necessitem ETags forts.

Dues maneres de generar-lo:

La Botiga Aroma fa servir totes dues: el camp versio de 03-05 per a recursos individuals que en tenen, i el hash per a col·leccions i per a tota la resta.

Les cometes no són decoratives: formen part de la sintaxi de la capçalera. Un ETag: a3f9 sense cometes és invàlid i molts intermediaris l'ignoren, amb la qual cosa la memòria cau deixa de funcionar sense donar cap error.

Una data HTTP:

És més feble que l'ETag per dues raons: té resolució d'un segon —dos canvis al mateix segon són indistingibles— i molts recursos no tenen una data de modificació fiable.

La Botiga Aroma emet totes dues quan disposa de dataActualitzacio, però l'ETag és el mecanisme principal.

Primera petició. El client no té res:

Dins dels 300 segons: el navegador serveix la seva còpia sense preguntar. Zero peticions, zero latència.

Passats els 300 segons: la còpia està caducada, però el navegador té el validador i pregunta:

Si res no ha canviat:

Sense cos. 284 bytes es converteixen en uns 150 de capçaleres, i el navegador renova el frescor de la seva còpia uns altres 300 segons.

Si el cafè va canviar (versio va passar a 8):

Tres detalls del 304 que s'equivoquen sovint:

• No porta cos. Enviar-ne un és un error de protocol.
• Sí que porta les capçaleres de memòria cau (Cache-Control, ETag, Vary): són les que renoven la validesa de la còpia desada.
• If-None-Match admet diversos ETags separats per comes, i el comodí * que significa «si existeix qualsevol representació».

Aquí hi ha el retrobament que vam anunciar a 03-05. If-None-Match serveix per llegir; If-Match serveix per escriure de manera segura.

Ningú no ha vist cap error. El preu 15,20 no va existir mai.

Si la versió actual ja no és la 7:

L'ETag: "v8" a la resposta d'error és un detall de disseny valuós: diu al client quina és la versió actual, així que pot rellegir, mostrar el conflicte a l'usuari i reintentar-ho sense una petició extra.

A 03-05 vam implementar la concurrència optimista amb versio dins del JSON. Funciona, però If-Match és millor per cinc raons:

L'última fila és la clau conceptual: el client ja va rebre l'ETag en llegir el recurs. No necessita entendre què és versio, ni extreure'l del cos: retorna l'etiqueta opaca que li van donar. Això és exactament el disseny d'HTTP.

I hi ha una decisió de contracte important: exigir If-Match o no.

La Botiga Aroma l'exigeix a PUT /v1/cafes/{id} i a PATCH /v1/comandes/{id}, perquè un preu o un estoc mal trepitjats tenen conseqüències comercials reals. Això obliga a afegir un codi nou al catàleg: precondicio_requerida (428). L'anotem explícitament, com exigeix la regla del projecte —el catàleg només creix—, i cal documentar-lo a openapi.yaml.

El comentari del mig és el punt fi: comprovar la versió al servei no n'hi ha prou; entre la lectura i l'escriptura hi ha una finestra. La garantia real la dona el WHERE versio = ? de l'UPDATE, que és atòmic. If-Match aporta la semàntica HTTP correcta i l'error primerenc; la correcció la continua donant la base de dades.

I Accept-Patch, que ja emetíem des de 02-05, acompanya això: diu al client quin format de pedaç accepta el recurs, igual que l'ETag li diu quina versió té.

Falta la peça que respon el 304 automàticament. L'estratègia: embolcallar res.json per calcular l'ETag just abans d'enviar i comparar amb If-None-Match.

Per què etagCondicional a la posició 10, just abans de les rutes. Ha d'embolcallar res.json abans que cap controlador el cridi, i alhora estar després de tot allò que pugui respondre pel seu compte (rate limiting, analitzador), perquè a aquelles respostes no els volem posar ETag. I per què compression a la 7, abans: la compressió ha d'embolcallar l'escriptura de la resposta com més aviat millor, i a més no ha d'intentar comprimir un 304 que no té cos.

Una nota pràctica: Express porta el seu propi ETag automàtic (app.set('etag', ...)), però és feble per defecte, cosa que l'inutilitza per a If-Match. El nostre middleware el substitueix amb ETags forts i amb control explícit sobre quan s'emeten.

Vary declara de quines capçaleres de la petició depèn la resposta. És el que impedeix que una memòria cau serveixi la resposta equivocada.

El cas d'Authorization mereix explicació perquè sembla la resposta òbvia i no ho és. Posar Vary: Authorization faria que la memòria cau desés una entrada per cada token diferent: com que els tokens canvien cada 15 minuts, la taxa d'encert seria pràcticament zero i el consum de memòria de la CDN, enorme. La manera correcta de protegir contingut personalitzat és Cache-Control: private, que impedeix directament que una memòria cau compartida el desi.

I l'advertiment de cost: cada capçalera a Vary multiplica les variants emmagatzemades. Vary: Accept, Accept-Language, Origin amb 2 tipus, 3 idiomes i 3 orígens són 18 còpies del mateix recurs. Declara només el que realment canvia la resposta.

«Només hi ha dues coses difícils en informàtica: la invalidació de memòria cau i posar noms a les coses.» — Phil Karlton

La dificultat és real: has distribuït còpies de les teves dades per navegadors i CDN de tot el món, i ara el preu de caf_001 ha canviat.

La memòria cau del navegador no es pot purgar. Un cop enviat max-age=3600, aquell navegador servirà la còpia durant una hora i no hi ha res a fer. És la raó que els TTL per al navegador siguin curts (60 s) i els de la CDN llargs (300 s amb s-maxage): la CDN sí que es pot purgar.

Les etiquetes de purga (surrogate keys) són el mecanisme que fa això manejable. Cada resposta declara a quins grups pertany:

I en canviar caf_001 es purga per etiqueta, en comptes d'haver d'enumerar les dotzenes d'URL afectades (la fitxa, la llista, la llista filtrada per origen, l'ordenada per preu...). Sense etiquetes, la invalidació de col·leccions és pràcticament impossible de fer bé.

Per què la invalidació per esdeveniment encaixa amb els webhooks. La Botiga Aroma ja emet esdeveniments signats cap a RàpidEnviaments (comanda.pagada, comanda.enviada). El mateix mecanisme serveix per a la memòria cau: quan el servei de catàleg canvia un preu, publica cafe.actualitzat i qui hi estigui subscrit —la CDN, una altra instància, el tauler— purga el seu. L'avantatge és el desacoblament: el servei que escriu no necessita conèixer totes les memòries cau que existeixen, només anunciar que alguna cosa ha canviat.

La memòria cau HTTP evita peticions. La memòria cau de servidor evita consultes a la base de dades per a les peticions que sí que arriben.

Què val la pena desar a la memòria cau a la Botiga Aroma:

Les dues últimes files són tan importants com les primeres: saber què no s'ha de desar a la memòria cau evita incidents. Desar l'estoc 60 segons significa vendre cafè que no existeix.

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

Quatre regles per no ficar-se en problemes:

1. Desa el resultat ja mapejat, no la fila crua. Així l'objecte a Redis no conté columnes internes: si un dia algú el bolca per depurar, no filtra preu_centims ni actiu.
2. La memòria cau mai no és una dependència dura. Si Redis cau, l'API funciona més lenta, no falla.
3. Espai de noms a les claus (aroma:cache:), separat de l'aroma:rl: del rate limiting de 04-04.
4. Invalida en escriure, a la mateixa operació que modifica la dada.

Un avís important: no desis objectes d'error ni excepcions a la memòria cau. A l'exemple, si el cafè no existeix es llança abans de desar res; si es desés el null, un cafè acabat de crear trigaria cinc minuts a aparèixer.

Escenari: caf_001 és el cafè més demanat i la seva entrada de memòria cau caduca a les 12:00:00. En aquell instant hi ha 500 peticions en vol. Les 500 fallen la memòria cau, les 500 consulten la base de dades i les 500 escriuen el mateix valor.

Això és l'estampida de memòria cau (cache stampede o thundering herd), i és especialment cruel perquè passa justament als recursos més populars, és a dir, en el pitjor moment possible.

Tres defenses, de menys a més eficaç:

TTL amb jitter. En comptes de 300 segons exactes, un valor aleatori entre 270 i 330. Reparteix les caducitats i evita que milers de claus expirin alhora. És una línia de codi:

Bloqueig (lock). Només un procés recalcula; la resta espera breument i reintenta la memòria cau:

Refresc anticipat. Desar juntament amb el valor el seu instant de caducitat i refrescar-lo abans que expiri, de manera probabilística. No hi ha mai un moment en què la clau no existeixi. És el que fa stale-while-revalidate a la memòria cau HTTP, aplicat al servidor.

L'estalvi en JSON és notable perquè és text amb molta repetició de claus:

Quan no comprimir:

• Respostes petites (per sota d'~1 kB): la sobrecàrrega supera l'estalvi.
• Contingut ja comprimit: imatges, vídeo, PDF, ZIP.
• Quan la CPU és el coll d'ampolla i la xarxa va sobrada.
• Històricament, respostes amb secrets al costat de dades controlades per l'atacant, pels atacs BREACH/CRIME. Amb Authorization: Bearer en comptes de galetes el risc pràctic és molt menor, però convé conèixer-lo.

Brotli comprimeix millor que gzip i l'admeten tots els navegadors moderns; la majoria de les CDN l'apliquen elles soles. Si tens CDN, l'habitual és deixar que ella comprimeixi i estalviar aquella CPU al teu procés.

Recuperant 01-03 amb perspectiva de rendiment:

Recordatori de 04-04: el keepAliveTimeout de Node ha de ser més gran que el del balancejador, o apareixeran 502 esporàdics impossibles de reproduir.

I la perspectiva que ordena les prioritats: en una petició mòbil típica, la latència de xarxa domina sobre tota la resta. Si la teva API respon en 40 ms i l'usuari és a 150 ms de distància, optimitzar la consulta SQL per baixar a 30 ms millora el total un 5 %. Reduir de cinc peticions a una (04-01) o servir des d'una CDN millora molt més. L'optimització més rendible gairebé mai no és al servidor.

Índexs. Cada filtre del contracte necessita el seu:

L'ordre de les columnes en un índex compost importa: (client_id, data_creacio) serveix per filtrar per client i ordenar per data, però no per ordenar per data sense filtrar per client. I els índexs no són de franc: accel·leren les lectures i alenteixen les escriptures, perquè cal mantenir-los.

Com verificar que es fan servir:

L'N+1, ara a la base de dades (a 04-01 el vam veure sobre HTTP):

Nota de seguretat sobre l'IN: els marcadors ? es generen a partir del nombre d'elements, i els valors van com a paràmetres. Mai no s'interpolen els ids al SQL (04-02). I cal acotar la mida de la llista, perquè els motors tenen un límit de paràmetres; amb limit màxim 100 estem molt per sota.

Consultes lentes. Un registre senzill detecta el que les proves no veuen mai:

El comentari assenyala una decisió de RGPD: la plantilla SQL es registra, els valors no.

Dos mecanismes del mòdul 2 que ara es llegeixen com a optimitzacions de primer ordre.

camps (02-05): si la llista d'Aroma Mòbil només mostra nom, preu i torrefacció, demanar l'objecte sencer malbarata amplada de banda i serialització.

Paginació (02-06): a més de ser obligatòria per disseny (04-01), és la defensa més efectiva contra la degradació amb el creixement. I el cursor de /comandes no és un caprici: amb desplacament=100000, el motor ha de localitzar i descartar 100.000 files abans de retornar-ne 20. Amb cursor, salta directament per índex.

Algunes operacions no caben al cicle d'una petició. Generar la factura PDF d'una comanda amb vint línies, o l'exportació de dades de l'exercici de 04-02, triguen segons.

Mantenir la connexió oberta és mala idea: esgota els processos, xoca amb els timeouts del balancejador i fa que una fallada de xarxa obligui a repetir tota la feina. El patró correcte:

El client consulta el recurs de tasca:

I en acabar:

Quatre detalls de disseny:

• 202 significa «acceptat, encara no fet», i és diferent de 201 («creat»). L'arbre de decisió de 02-04 ho contemplava.
• La tasca és un recurs, amb la seva URI, la seva representació i els seus _links. No és un mecanisme a part.
• Retry-After a la consulta evita que el client pregunti cada 50 ms. És el mateix mecanisme de 04-04, aplicat a alguna cosa que no és un error.
• 303 See Other en acabar redirigeix al recurs final. I el codi operacio_en_curs del catàleg cobreix el cas de demanar la factura mentre s'està generant.

Per al tauler intern, en comptes de sondejar es fan servir SSE, que ja formen part de l'arquitectura de la Botiga Aroma: el servidor empeny el canvi d'estat quan passa.

Tot l'anterior és inútil —o contraproduent— si s'aplica a cegues. L'ordre correcte és sempre: mesurar, trobar el coll d'ampolla real, arreglar això, tornar a mesurar.

Deu peticions: nou de 20 ms i una de 2.000 ms.

La mitjana és un promig de dues poblacions diferents i no en descriu cap. Els percentils són el que cal mirar, i el p99 és el més important, perquè una pàgina que fa 10 peticions té ~10 % de probabilitat que almenys una caigui al p99. El teu p99 és l'experiència habitual dels teus usuaris més actius.

Es decideix abans d'optimitzar, i es converteix en el criteri per saber quan parar:

El login és deliberadament el més lent: bcrypt amb cost 12 triga ~100 ms a propòsit (03-06). Això no és un problema de rendiment que calgui arreglar, és una defensa funcionant. Sense el pressupost escrit, algú acabarà «optimitzant-lo» abaixant el cost de bcrypt.

Sortida típica:

Com llegir-ho sense enganyar-se:

• Mira el p99 (columna 99 %), no la mitjana.
• Compara sempre contra una línia base presa abans del canvi. Un número absolut tot sol no diu res.
• Una sola màquina no és producció: no hi ha latència de xarxa real, ni CDN, ni altres instàncies, ni dades de debò.
• Amb poques dades, tot va ràpid. Prova amb un volum realista: una taula de 100 files cap a la memòria i amaga la manca d'índexs.
• Vigila la CPU i la memòria durant la prova. Si la CPU és al 100 %, el coll és teu; si és al 20 % i la latència puja, el coll és a la base de dades o en un tercer.

1. Mesura i localitza l'endpoint lent real, amb dades de producció.
2. Es pot evitar la petició? Memòria cau HTTP. És el guany més gran possible.
3. Es pot reduir el nombre de peticions? expandir (04-01).
4. Es pot evitar la consulta? Memòria cau de servidor.
5. Es pot fer la consulta més barata? Índexs, N+1, camps.
6. Es pot fer després? 202 i treball asíncron.
7. Torna a mesurar i comprova contra el pressupost.

I un advertiment final: la memòria cau afegeix complexitat i una classe nova de bugs —dades obsoletes, invalidació incompleta, incoherències entre nivells—. Si un endpoint respon en 15 ms i es crida deu vegades al dia, desar-lo a la memòria cau no aporta res i sí que afegeix una manera més de fallar.

Creure que no-cache significa «no desar a la memòria cau». Significa «revalida sempre». La que impedeix desar és no-store.

Oblidar private en respostes personalitzades. Una CDN pot servir les comandes d'un usuari a un altre. És la fuita de dades més greu d'aquesta lliçó.

Desar respostes d'error a la memòria cau. Un 429 desat cinc minuts converteix un bloqueig d'un minut en cinc.

Fer servir ETags febles per a If-Match. No garanteixen igualtat exacta i l'estàndard no ho permet. L'ETag automàtic d'Express és feble.

Retornar cos en un 304. És un error de protocol; a més anul·la l'estalvi.

Oblidar Vary. Amb negociació de contingut o CORS, provoca respostes creuades intermitents i impossibles de reproduir.

Desar l'estoc a la memòria cau. Provoca sobrevenda. Hi ha dades que han de ser exactes sempre.

Posar TTL llargs al navegador. No es poden purgar. Curts al navegador, llargs a la CDN amb s-maxage.

Optimitzar sense mesurar. La major part del temps es perd on ningú no mira, i la feina es dedica on ja era ràpid.

Consell: comença pel catàleg. És el 80 % del trànsit i el més cacheable. Ben resolt, resol gairebé tot.

Consell: fes que la memòria cau sigui observable. Sense mètriques d'encerts i fallades no saps si funciona. És tema de 04-07.

Consell: prova el 304 explícitament. És fàcil que el middleware deixi de funcionar en un refactor i ningú no se n'assabenti: només es nota a la factura d'amplada de banda.

Per a cada recurs, decideix el Cache-Control complet i si emetries ETag. Justifica cada elecció:

1. GET /v1/cafes?origen=Etiòpia — catàleg filtrat, públic.
2. GET /v1/clients/cli_842/preferencies — preferències de l'usuari autenticat.
3. GET /v1/cafes/caf_001/imatge — imatge el nom de la qual inclou un hash.
4. POST /v1/sessions — retorna tokens.
5. GET /v1/comandes/com_5001 — comanda del mateix client, consultada sovint.
6. GET /v1/cafes/caf_001/ressenyes?ordenar=-dataCreacio — ressenyes públiques.

Implementa l'esborrat condicional d'una ressenya: DELETE /v1/ressenyes/{id} ha d'exigir If-Match, retornar 204 si la versió coincideix, 412 conflicte_versio si no, 428 precondicio_requerida si falta la capçalera i 404 si no existeix. Escriu la ruta, el servei i una prova d'integració dels quatre casos.

GET /v1/comandes?limit=20&expandir=linies.cafe té un p50 de 45 ms i un p99 de 1.800 ms. La CPU del servidor és al 25 % durant la prova de càrrega. Enumera almenys quatre causes possibles, ordenades per probabilitat, i digues com verificaries i corregiries cadascuna.

Solució 1

Solució 2

Nota de disseny: el 404 es comprova abans que l'If-Match, perquè no té sentit parlar de la versió d'una cosa que no existeix, i perquè respondre 412 en un recurs inexistent filtraria informació sobre la seva existència.

Solució 3

Que la CPU sigui al 25 % descarta que el coll sigui el mateix procés Node. La distància entre p50 i p99 (40×) apunta a alguna cosa que passa només de vegades, no a un cost constant.

Procediment: primer el registre de consultes lentes de l'apartat 14, que en cinc minuts distingeix entre 1-2-3 (base de dades) i 5-6 (procés). Després mesurar contra el pressupost (p99 de 400 ms per a escriptures; per a aquesta lectura hauria d'estar a l'entorn de 150 ms) i parar quan es compleixi, ni abans ni després.

La restricció «cacheable» de 01-04 ja és implementació. Coneixes els quatre nivells de memòria cau i la regla que evita la fuita més greu —private en tot allò que depengui de qui pregunta—; domines Cache-Control directiva a directiva, inclòs aquell no-cache que no significa «no desar a la memòria cau» i aquell stale-while-revalidate que elimina l'espera del refresc; tens la política de la Botiga Aroma recurs a recurs, amb el catàleg desat a la memòria cau i /v1/comandes revalidat sempre. Has implementat la validació condicional amb ETag fort —del hash del cos o del camp versio que ja existia— i el flux complet del 304. I sobretot s'ha tancat el cercle que va quedar obert a 03-05: If-Match i el 412 resolen l'actualització perduda amb la semàntica estàndard d'HTTP, funcionen amb DELETE, els entenen els intermediaris i reutilitzen el mateix ETag que el client va rebre en llegir; a canvi, el catàleg d'errors creix amb precondicio_requerida (428), que cal documentar a openapi.yaml. Al projecte tens src/middleware/cache.js amb cacheDe, etagCondicional i exigirIfMatch, src/serveis/cache.js amb cache-aside i bloqueig, src/serveis/cache-invalidacio.js, i compression a la posició 7 amb etagCondicional a la 10 de src/app.js. Més enllà de la memòria cau: compressió, keep-alive, índexs, l'N+1 resolt amb una consulta agrupada, camps, paginació per cursor i el 202 amb recurs de tasca per a la factura. I, el primer encara que s'expliqui al final, el pressupost de latència, els percentils davant de la mitjana i autocannon per mesurar abans de tocar res.

Només queda una cosa abans de tancar el mòdul, i és la que fa possible tota la resta: saber què està passant. A 04-07, Observabilitat: logs, mètriques i traces, substituirem per fi el console.log de la posició 5 de src/app.js per logs estructurats amb pino, amb un logger fill per petició que arrossega el tracaId que emetem des de 03-02, els camps que cal registrar sempre i els que mai —contrasenyes, tokens, dades personals— amb la seva redacció automàtica. Instrumentarem la Botiga Aroma amb prom-client i els quatre senyals d'or, exposant /metriques protegit i fora de /v1, amb l'advertiment sobre la cardinalitat que rebenta els sistemes de mètriques. Veurem les traces distribuïdes amb traceparent i OpenTelemetry sobre un POST /v1/comandes complet —validació, SQL, gRPC d'inventari i webhook—, la diferència entre liveness i readiness a /salut, i com s'alerta sobre símptomes i SLO en comptes de sobre la CPU. I tancarem el mòdul amb el balanç de tot el que s'ha endurit.