La lliçó anterior va acabar amb dues preguntes. La primera: cal un Deployment a EKS, amb les seves rèpliques, les seves sondes, el seu HPA i la seva guàrdia, per generar tres miniatures cada vegada que la Formatgeria Montblanc puja una foto, o per produir un PDF de factura quan arriba un pagament.confirmat? Són tasques petites, esporàdiques, sense estat, que responen a un esdeveniment i acaben. La segona: per què la foto de formatge-curat ha de viatjar des de la regió eu-west-1 fins al mòbil de l'Anna a València a cada visita, pagant egress i 40 ms de latència, quan podria estar desada a vint quilòmetres d'ella? I n'hi ha una tercera, que ja va treure el cap a 08-02: què fa furgoneta-3 amb les seves posicions durant un túnel de tres minuts, o la parada de l'Horta La Vega al mercat de Lleida quan la connexió cau i continuen arribant clients? Les tres preguntes tenen respostes que surten del model "servei en un clúster en una regió": serverless, on el proveïdor executa funcions efímeres en resposta a esdeveniments i cobra per invocació; i edge computing, on el còmput i les dades s'acosten a qui els fa servir, sigui una CDN, una funció a la vora de la xarxa o un dispositiu que funciona sense connexió. Aquesta lliçó desenvolupa tots dos, amb el seu model d'execució, els seus límits, els seus casos adequats i inadequats a Quilòmetre Zero, i el codi que els implementa: una Lambda de miniatures, una de factures, la saga de comanda reescrita en Step Functions, un Worker de Cloudflare que verifica el JWT a la vora i un agregador local per a la furgoneta. El projecte final (08-05) ho integrarà tot.

1. Serverless i FaaS: el model d'execució
2. Arrencada en fred, límits, concurrència i preu
3. Casos adequats i inadequats: els quatre de Quilòmetre Zero
4. Serverless més enllà de FaaS: cues, bases de dades, API Gateway i Step Functions
5. Patrons: fan-out, idempotència obligatòria i DLQ
6. Observabilitat, proves locals, lock-in i cost a gran escala
7. Codi serverless: miniatures, factures, SAM i la saga en Step Functions
8. Edge computing: per què acostar el còmput
9. CDN: desar fotos i catàleg a la memòria cau a prop de l'Anna
10. Funcions a la vora: verificació de JWT i personalització
11. Edge per a IoT: la furgoneta i el mercat sense connexió
12. El continu núvol-edge-dispositiu i la seguretat a la vora
13. Errors Comuns i Consells
14. Exercicis
15. Conclusió

"Serverless" no vol dir que no hi hagi servidors: vol dir que no són nostres ni els veiem. El proveïdor els aprovisiona, els escala i els retira; nosaltres lliurem codi i paguem pel que s'executa. La forma més pura és FaaS (Function as a Service): AWS Lambda, Google Cloud Functions, Azure Functions. A 08-03 la taula de responsabilitat compartida ja ho anomenava; aquest és el seu model d'execució:

1. Es produeix un esdeveniment: un objecte arriba a un bucket, un missatge entra en una cua o un tòpic, una petició HTTP arriba a un endpoint, un temporitzador salta.
2. El proveïdor busca una instància de la funció a punt (un microcontenidor amb el runtime de Python i el nostre codi). Si no n'hi ha cap de lliure, en crea una (arrencada en fred).
3. Invoca el gestor (handler(esdeveniment, context)) amb l'esdeveniment serialitzat. La funció fa la seva feina i retorna.
4. La instància queda congelada uns minuts per si arriba un altre esdeveniment; si no arriba, es destrueix. No hi ha estat entre invocacions en què es pugui confiar (el sistema de fitxers temporal pot sobreviure, però no està garantit).
5. Si arriben mil esdeveniments alhora, el proveïdor crea fins a mil instàncies en paral·lel (escalat a milers); si no n'arriba cap, no n'hi ha cap (escalat a zero) i no es paga res.

La comparació amb el Deployment de 07-05 resumeix la diferència de model:

Arrencada en fred (cold start): crear la instància, carregar el runtime i executar el codi d'inicialització (imports, connexions) abans de la primera invocació. En Python amb poques dependències són 100-300 ms; amb Pillow, boto3 i un client de Kafka, 1-2 s; dins d'una VPC, una mica més. És acceptable per processar una foto i no per respondre a l'Anna. Es mitiga amb concurrència aprovisionada (instàncies mantingudes calentes, que es paguen encara que no es facin servir: es perd l'escalat a zero), amb paquets petits, i traient la inicialització pesada fora del gestor perquè s'executi una vegada per instància i no per invocació.

Límits: temps màxim per invocació (15 min a Lambda, 9-60 min a Cloud Functions segons la generació), memòria (de 128 MB a 10 GB; la CPU s'assigna en proporció a la memòria, així que una funció lenta de vegades s'accelera donant-li memòria), mida del paquet (250 MB descomprimit; o una imatge de contenidor de fins a 10 GB), mida de l'esdeveniment (6 MB síncron, 256 KB asíncron), espai temporal (/tmp de fins a 10 GB).

Concurrència: el nombre d'instàncies simultànies. Té un límit per compte i regió (1 000 per defecte a Lambda, ampliable) i es pot reservar per funció (perquè una funció descontrolada no esgoti la quota de les altres) o limitar (per no esgotar la base de dades del darrere: si km0_analitica accepta 100 connexions, la funció que hi escriu no pot tenir 500 instàncies). Aquest límit és el bulkhead de 07-04 en versió serverless.

Preu: per nombre d'invocacions (de l'ordre de 0,20 € per milió) més per GB-segon d'execució (memòria assignada × durada; de l'ordre de 0,000017 € per GB-s), amb un tram gratuït mensual. Una funció de miniatures amb 512 MB que triga 800 ms costa ≈ 0,000007 € per foto: 100 000 fotos al mes, menys d'1 €. És el que fa que serverless sigui imbatible per a càrregues esporàdiques i el que el fa car per a càrregues constants (apartat 6).

Amb aquest filtre, Quilòmetre Zero identifica quatre tasques que avui viuen com a codi dins dels serveis (o com a cron jobs a Kubernetes) i que encaixen millor com a funcions:

1. Miniatures en pujar una foto a km0-fotos. A 04-03 la Formatgeria Montblanc pujava fotos/formatge-curat/original.jpg per URL presignada i "un procés de miniatures" generava les de 300 i 800 px. Aquell procés era un consumidor amb un bucle. Com a funció: esdeveniment s3:ObjectCreated → Lambda amb Pillow → escriu miniatura-300.jpg i miniatura-800.jpg. Esporàdic (centenars de fotos al dia, amb pics quan un productor puja el catàleg sencer), sense estat, 1 s per foto.
2. Factura PDF al pagament.confirmat. Avui és un consumidor de comandes.esdeveniments dins de comandes. Com a funció: esdeveniment de Kafka (MSK com a origen d'esdeveniments de Lambda, per lots) → generar el PDF → escriure'l a km0-factures → notificar. Ritme de les comandes: milers al dia, pics en campanya, sense estat.
3. Webhooks de la passarel·la de pagaments. La passarel·la notifica de manera asíncrona els cobraments diferits i les devolucions amb un POST a una URL nostra. És un endpoint que rep poques crides, ha d'estar sempre disponible, verificar una signatura i publicar un esdeveniment: API Gateway + Lambda, sense ocupar una rèplica de pagaments per esperar.
4. Tasques programades lleugeres. Caducar reserves d'estoc no confirmades cada minut, netejar sessions, comprovar que el DAG d'Airflow ha acabat: temporitzador (EventBridge) → Lambda. Substitueixen CronJobs de Kubernetes que ocupaven recursos per executar 200 ms de feina.

I el que no es mou a funcions, amb la raó: comandes i cataleg (latència exigida a persones, pool de connexions, Kong i mesh al davant), el servidor WebSocket de 08-02 (estat i connexions llargues; hi ha serveis gestionats de WebSocket, però el fan-out entre instàncies i la lògica de subscripció són justament el que no hi encaixa), els consumidors de Flink (estat i checkpoints), els treballs de Spark (hores).

FaaS és la part visible; al seu voltant hi ha serveis "serverless" en el sentit de sense capacitat a aprovisionar i amb pagament per ús:

Step Functions mereix atenció perquè substitueix una cosa que el curs va construir amb esforç. L'OrquestradorSagaComanda de 03-05 persistia l'estat de cada saga a la taula sagas, reintentava les fallades transitòries, distingia les permanents i executava les compensacions en ordre invers. Step Functions fa exactament això com a servei: l'estat de cada execució el desa el proveïdor (amb l'historial complet de cada pas), els reintents i els Catch es declaren per pas, i les compensacions són branques del graf. El que es perd: l'orquestrador viu fora del clúster, cada pas és una invocació (amb la seva latència i el seu cost), la definició és JSON i no Python, i és el més específic del proveïdor que hi ha (lock-in total). La comparació completa és a l'apartat 7, amb la saga reescrita.

Fan-out amb cues. Un esdeveniment que s'ha de processar de diverses maneres (una foto pujada: miniatures, anàlisi de contingut, actualització de la fitxa) no dispara tres funcions directament des d'S3; es publica en un tòpic (SNS o EventBridge) que el lliura a una cua per consumidor (SQS), i cada cua dispara la seva funció. Les cues desacoblen (si la funció d'anàlisi falla, les miniatures es generen igualment), absorbeixen pics (un productor que puja 2 000 fotos no crea 2 000 × 3 instàncies de cop: la cua les dosifica amb el límit de concurrència) i donen reintents i DLQ.

Idempotència obligatòria. El proveïdor lliura els esdeveniments almenys una vegada i reintenta automàticament quan la funció falla o esgota el temps: una funció que triga 16 minuts per un pic de mida es torna a invocar, i si la primera instància havia escrit la meitat del resultat, la segona parteix d'aquest estat. Tot el que es va veure a 02-05 sobre consumidors idempotents s'aplica amb més força, perquè aquí els reintents no els controlem nosaltres: cada funció ha de ser segura davant la repetició. Les tècniques: claus de sortida deterministes (la miniatura s'escriu sempre a la mateixa clau: escriure-la dues vegades és inofensiu), taula d'idempotència a DynamoDB amb l'id de l'esdeveniment (la factura F-2026-000124 es genera una sola vegada), i operacions condicionals (PutItem amb attribute_not_exists).

DLQ. Després de n reintents (configurable per funció o per cua), l'esdeveniment va a una cua de missatges morts, amb alerta (07-01) i procediment de reprocessament: la DLQ de 02-05, gestionada. Sense DLQ configurada, un esdeveniment enverinat (una imatge corrupta que fa fallar Pillow) es reintenta fins a esgotar la política i es perd en silenci.

Observabilitat. Les funcions emeten logs a CloudWatch (o Cloud Logging) automàticament, i mètriques d'invocacions, errors, durada i throttles. El que cal afegir és el mateix que a 07-02: logs estructurats amb l'X-Request-Id o l'id_esdeveniment per correlacionar, i traces amb OpenTelemetry (o X-Ray) que enllacin la funció amb el servei que va produir l'esdeveniment, perquè una petició de l'Anna que acaba en una factura travessa comandes, Kafka i la Lambda, i sense propagació de context la traça es talla a Kafka. El serveis/comu/traces.py de 07-02 s'empaqueta amb la funció com a capa (layer).

Proves locals. Una funció no es pot executar "sense el proveïdor" si no és amb emuladors: AWS SAM (sam local invoke, sam local start-api) executa la funció en un contenidor amb un esdeveniment d'exemple; LocalStack emula S3, SQS, DynamoDB i més en Docker, cosa que permet proves d'integració amb Testcontainers (07-06) sense compte d'AWS. Cap dels dos és perfecte (els permisos IAM i els límits reals només es veuen al proveïdor), així que el pipeline desplega a un entorn de staging real per a les proves de contracte.

Lock-in. És el més alt de tot el que s'ha vist: el format de l'esdeveniment, el gestor, els serveis del voltant (SQS, DynamoDB, Step Functions) són del proveïdor. Es mitiga separant el gestor (adaptador de 10 línies) de la lògica (funcions Python pures, provables sense proveïdor), com es fa a l'apartat 7; però cal acceptar-ho: qui tria Step Functions tria AWS.

Cost a gran escala. El preu per invocació és imbatible a baixa freqüència i es torna car a alta: una funció amb 512 MB que corre constantment (per exemple, 100 invocacions/s de 200 ms cadascuna, 24 h al dia) consumeix ≈ 2,6 milions de GB-s al mes ≈ 45 €, més 260 milions d'invocacions ≈ 52 €: uns 100 €/mes, davant de ≈ 30 € d'un Pod petit en un node ja pagat. La regla aproximada: quan la utilització mitjana supera el 30-40 % d'un contenidor equivalent, el contenidor surt més barat. Per això les miniatures i les factures són serverless i comandes no.

L'estructura afegida a km0/:

Decisions a destacar: la idempotència es basa en l'ETag de l'original desat com a metadada de la miniatura, de manera que una reinvocació no refà feina i una foto nova amb la mateixa clau (ETag nou) sí que la refà; CacheControl: immutable és la promesa de 04-03 de no sobreescriure claus desades a la CDN, que aquí es compleix perquè la web referencia miniatura-800.jpg?v=<etag>; i el gestor no conté negoci, perquè processar_objecte es provi amb un client fals i perquè el lock-in es limiti a aquestes línies.

Un matís important sobre l'ordre de les operacions: reclamar es fa abans de generar el PDF. Si la funció mor després de reclamar i abans d'escriure, la factura no es generarà mai en un reintent (la marca ja existeix). L'alternativa (reclamar després d'escriure) permet duplicats si mor entremig. Com que escriure dues vegades la mateixa clau d'S3 és inofensiu (idempotent per si mateix), la tria correcta aquí és reclamar després, o fer servir l'existència de l'objecte com a marca. Es deixa tal com està a propòsit per a l'exercici 1, que demana corregir-ho: és el tipus de raonament sobre el punt d'ack que 02-05 va ensenyar, i en serverless no hi ha excusa per no fer-lo.

Tres detalls del template.yaml que eviten errors clàssics: el filtre per sufix original.jpg impedeix que l'escriptura d'una miniatura torni a disparar la funció (un bucle infinit que també seria una factura infinita); ReservedConcurrentExecutions acota el dany d'un pic; i l'origen d'esdeveniments MSK converteix Lambda en un grup de consumidors més de comandes.esdeveniments, amb el mateix model de particions i offsets de 02-04, cosa que vol dir que una fallada persistent de la funció bloqueja l'avenç d'aquella partició per a aquell grup (i només per a aquell grup) fins que el lot va a la DLQ. Es desplega amb sam build && sam deploy --guided la primera vegada, i des del pipeline després.

La saga de 03-05 (reservar estoc → cobrar → confirmar; compensar en ordre invers davant d'una fallada permanent), expressada en Amazon States Language, amb cada pas invocant una funció (o, en producció, el servei corresponent via API):

Compareu-ho amb l'OrquestradorSagaComanda de 03-05:

La decisió de Quilòmetre Zero, que l'ADR-006 de 08-05 formalitza: la saga de comanda es queda a comandes, perquè és al camí crític (latència), té un volum constant (cost) i ja està construïda i provada; Step Functions es reserva per a fluxos de baixa freqüència i llarga durada on la visibilitat i els reintents declaratius compensen, com la baixa d'un productor (cancel·lar els seus productes, liquidar els seus pagaments, arxivar les seves fotos, tot amb esperes de dies).

Tot l'anterior continua a la regió del proveïdor. L'edge computing mou còmput i dades cap a la vora: als punts de presència d'una CDN (centenars de ciutats), a les antenes o passarel·les de l'operador, o als mateixos dispositius. Quatre raons, i per a cadascuna un cas de Quilòmetre Zero:

Una CDN (Content Delivery Network: CloudFront, Cloudflare, Fastly, Akamai) és una xarxa de servidors de memòria cau distribuïts pel món, davant de l'origen. 04-05 la va situar com a capa de memòria cau i 04-03 la va justificar per l'egress; aquí es dissenya.

Com funciona. El DNS de km0.example apunta a la CDN; el navegador de l'Anna a València resol al punt de presència més proper; si l'objecte és a la seva memòria cau (hit), el serveix en 5-10 ms; si no (miss), el demana a l'origen (S3 per a les fotos, Kong per a l'API), el desa segons les capçaleres de memòria cau i el serveix. El hit ratio és la mètrica: amb 4 200 productes i immutable, supera el 95 % després de l'escalfament.

Cache keys. La clau de memòria cau és, per defecte, l'URL completa (amb paràmetres de consulta). Dues conseqüències: miniatura-800.jpg?v=abc i ?v=def són objectes diferents, que és exactament el que es vol per versionar (04-03); i una URL amb paràmetres irrellevants (?utm_source=...) fragmenta la memòria cau i abaixa el hit ratio, així que es configura quins paràmetres formen part de la clau. Capçaleres com Accept-Language o cookies es poden afegir a la clau (amb compte: cada valor multiplica les variants).

TTL per tipus de contingut i invalidació:

La invalidació explícita (purge per URL o per etiqueta) existeix però és lenta (de segons a minuts per propagar-se a tots els punts de presència) i sovint es cobra; el disseny correcte l'evita per a l'immutable i la fa servir només per al semiestàtic (la fitxa) com a complement del TTL curt. És el mateix principi de 04-05: "TTL com a xarxa de seguretat, invalidació explícita com a mecanisme".

Les CDN modernes executen codi al punt de presència (Cloudflare Workers, Lambda@Edge i CloudFront Functions, Fastly Compute): funcions molt petites (mil·lisegons, pocs MB) que veuen la petició abans que arribi a l'origen o la resposta abans que arribi al client. Els seus usos a Quilòmetre Zero:

• Verificació de JWT a la vora. Una petició amb un token invàlid o caducat es rebutja a València, sense viatjar a Irlanda ni ocupar Kong: menys latència per a l'error i menys càrrega a l'origen davant d'un atac. La vora verifica la signatura (amb la clau pública de Keycloak, desada a la memòria cau) i la caducitat; l'autorització fina continua al servei (06-01), i Kong torna a verificar (defensa en profunditat, com a 08-02).
• Personalització sense perdre la memòria cau. La fitxa de formatge-curat és igual per a tothom tret del mercat (preu i disponibilitat per ciutat). El Worker llegeix el mercat d'una cookie o de la geolocalització de la petició i l'afegeix a la clau de memòria cau (/productes/formatge-curat?mercat=valencia), de manera que hi ha una variant per mercat i no una per usuari.
• Redireccions i A/B. Redirigir /es/... segons Accept-Language, enviar el 10 % dels usuaris a la nova pàgina de producte i mesurar, sense desplegar res a l'origen.
• Servir des de la vora amb reserva. Si l'origen falla, servir l'última versió desada encara que hagi caducat (stale-if-error): el catàleg continua visible durant un incident.

El Worker no conté lògica de negoci ni accedeix a bases de dades: verifica, decideix la clau de memòria cau i reenvia. Tot el que necessiti l'estat real (estoc, comandes) continua anant a l'origen. I hi ha una restricció de disseny que el codi respecta: la resposta desada per mercat no pot contenir dades de l'usuari; si cataleg afegís "els teus preferits" a la fitxa, la memòria cau per mercat serviria els preferits de l'Anna al Marc. Per això la fitxa és pública i els preferits són una altra crida, private.

La vora més extrema és el dispositiu. Dos casos a Quilòmetre Zero exigeixen funcionar sense connexió i sincronitzar després:

La furgoneta. A 08-02, paho encuava en memòria les posicions durant el túnel i les enviava de cop en sortir: 36 missatges que no interessaven a ningú un per un. Un agregador local al dispositiu fa tres coses millor: desa les posicions en una cua persistent a disc (SQLite) perquè un reinici de l'app no les perdi, agrega localment (mentre no hi ha xarxa, resumeix el tram en un únic missatge amb distància recorreguda, temps i trajectòria simplificada), i en recuperar la connexió envia primer la posició actual (l'urgent) i després el resum (l'històric). És l'edge com a filtre: el núvol rep menys dades i més útils.

La parada del mercat. L'Horta La Vega ven al mercat de Lleida amb un terminal que descompta estoc local. Sense connexió, continua venent: és una rèplica que accepta escriptures mentre està desconnectada, és a dir, replicació multilíder (03-04) amb conflictes garantits (el núvol reserva 3 carbassons per a una comanda en línia mentre la parada en ven 5 dels 6 que quedaven). 03-01 va donar l'eina perquè la fusió sigui determinista: els CRDT. Un comptador de vendes de la parada com a G-Counter (només incrementa; fusionar és prendre el màxim per rèplica) se sincronitza sense conflicte; l'estoc disponible, que és una resta, no és un CRDT pur, i es resol amb la regla de negoci de 03-04: la parada té autoritat sobre el seu estoc físic (inv-lleida-parada) i el núvol sobre les reserves en línia, i la reconciliació pot deixar una comanda en línia sense estoc, que la saga rebutja amb compensació. El que l'edge no pot fer és prometre consistència forta sense connexió: és la partició de 03-02, i la parada tria disponibilitat.

Amb l'agregador, l'exercici 2 de 08-02 canvia de resposta: en sortir del túnel, l'Anna rep una posició (l'actual), analitica rep un tram amb la distància i deu punts (suficient per al càlcul de distància de Flink, que ara pot sumar el distancia_m en comptes de reconstruir-la), i el broker no rep 36 missatges. Els seq continuen sent monòtons i persistits, així que la deduplicació de 08-02 continua funcionant. El que cal afegir al costat del núvol és un consumidor del nou tòpic tram al pont MQTT → Kafka, cap a un tòpic repartiment.trams.

Núvol, vora i dispositiu no són alternatives sinó un continu: cada càlcul i cada dada se situen on l'equilibri entre latència, amplada de banda, autonomia, capacitat i control sigui millor.

Seguretat a la vora. Com més lluny del centre, menys control físic: un Worker corre en infraestructura d'un tercer, el terminal del mercat és damunt d'una taula i la furgoneta pot ser robada. Cinc regles:

1. Res de secret a la vora de xarxa: el Worker verifica signatures amb la clau pública; mai no té la privada ni credencials de bases de dades. Els secrets que un Worker necessita (una clau d'API de l'origen) es desen al magatzem de secrets de la CDN, no al codi.
2. El dispositiu s'autentica amb identitat pròpia i revocable: un certificat o credencial per dispositiu (la contrasenya MQTT de furgoneta-3 de 08-02, emesa en donar-lo d'alta), que es revoca al broker si el dispositiu es perd, i que només autoritza el seu prefix de tòpics (ACL).
3. Dades en repòs xifrades al dispositiu: la cua SQLite amb posicions i les comandes amb adreces de clients es xifren (SQLCipher o el magatzem segur del sistema operatiu) i s'esborren quan se sincronitzen.
4. Mínima dada a la vora: el terminal de la parada no necessita l'adreça ni el telèfon de l'Anna; rep només el que li cal per vendre (producte, unitats, preu), i el que envia (vendes) no porta dades personals.
5. La vora no és la veritat: qualsevol dada que vingui del dispositiu es valida al núvol (el pont de 08-02 comprovava que el repartidor del payload coincideix amb el del tòpic; el tram amb 900 km en 3 minuts es descarta com a invàlid). Un dispositiu compromès pot mentir; el disseny ha de limitar el que una mentida pot causar.

• Funcions per a tot. Un consumidor constant de 500 esdeveniments/s o un servei amb SLO de latència són més barats i previsibles com a contenidor. Serverless per a l'esporàdic, el dirigit per esdeveniments i el que escala a zero.
• Suposar una sola execució. El proveïdor reintenta; la funció que no és idempotent genera dues factures o tres miniatures. Claus deterministes, marques d'idempotència, operacions condicionals.
• La funció que es dispara a si mateixa. Escriure la miniatura al mateix bucket que dispara la funció, sense filtre per prefix o sufix: bucle infinit i factura il·limitada. Filtre a l'esdeveniment i comprovació al codi.
• Connexions a base de dades des de mil instàncies. Mil Lambdes obren mil connexions a PostgreSQL. Límit de concurrència, RDS Proxy, o DynamoDB per a l'estat de les funcions.
• Inicialització dins del gestor. Carregar Pillow o crear el client d'S3 a cada invocació multiplica la durada i el cost. Fora del gestor, una vegada per instància.
• Sense DLQ. Un esdeveniment enverinat es reintenta i es perd sense que ningú ho sàpiga. DLQ amb alerta i procediment de reprocessament, sempre.
• Desar a la CDN respostes amb dades personals. Un public a /api/v1/comandes serveix les comandes de l'Anna al Marc. private, no-store per a tot el que és personal, i clau de memòria cau per mercat, mai per usuari, per al que és compartit.
• Sobreescriure objectes desats a la CDN. La memòria cau no se n'assabenta. Claus immutables amb versió (?v=<etag>), com es va decidir a 04-03.
• Confiar en el dispositiu. Valida al núvol tot el que vingui de la vora; assumeix que pot estar compromès.
• Consell: separa sempre gestor (adaptador del proveïdor) i lògica (Python pur). Les proves es fan sobre la lògica; el lock-in es limita a l'adaptador.
• Consell: calcula el cost de cada funció a la freqüència real i a deu vegades la real. Si a deu vegades continua sent barata, és un bon cas; si es dispara, prepara la sortida cap a contenidor.

A serverless/factures/handler.py, reclamar(id_esdeveniment) s'executa abans de generar i escriure el PDF. (a) Descriu la fallada concreta que això produeix i amb quina probabilitat passa. (b) Reescriu la part del gestor perquè la idempotència sigui correcta, raonant per què escriure dues vegades a S3 és acceptable i què passa si el procés mor en cada punt possible. (c) Seria diferent la resposta si, en comptes d'escriure un PDF a S3, la funció enviés un correu amb la factura?

Durant la campanya, la web serveix 6 milions de vistes de producte al dia; cada vista descarrega una miniatura-800 (180 KB) i la fitxa JSON (4 KB). (a) Amb el disseny de l'apartat 9 (fotos immutable, fitxa amb max-age=60), estima el hit ratio esperable de cada tipus i l'egress diari des d'S3 i des de Kong, davant de servir-ho tot des de l'origen. (b) Un dia, la Formatgeria Montblanc canvia la foto de formatge-curat i es queixa que "alguns clients continuen veient l'antiga". Què ha fallat, si el disseny és correcte? (c) L'equip proposa afegir el nom d'usuari a la fitxa ("Hola, Anna") per personalitzar-la. Explica l'impacte en la memòria cau i proposa una alternativa.

Per a cada flux, decideix si Quilòmetre Zero l'hauria d'implementar amb l'orquestrador propi de 03-05, amb Step Functions, o amb una simple funció disparada per esdeveniment, i justifica-ho amb cost, latència, durada i visibilitat: (a) la saga de confirmació de comanda (1,2 M al mes en campanya, al camí crític); (b) la baixa d'un productor (desenes a l'any: cancel·lar productes, esperar que es lliurin les comandes en curs, liquidar pagaments als 30 dies, arxivar fotos, notificar); (c) el reintent de cobraments diferits que la passarel·la rebutja temporalment (centenars al dia, un reintent cada 6 hores durant 3 dies).

Exercici 1.

(a) Si la funció mor (timeout de 120 s per un lot gran, error de xarxa amb S3, retirada de la instància) després de reclamar i abans de put_object, la marca factura#<id_esdeveniment> queda escrita i el PDF no. Al reintent de Lambda (o al lot següent, perquè l'offset no ha avançat), reclamar retorna False i la factura se salta per sempre: factura perduda, sense error ni alerta. La probabilitat per esdeveniment és baixa (la finestra són uns mil·lisegons entre dues crides), però amb 1,2 M comandes al mes i reinicis d'instàncies, passarà diverses vegades al mes.

(b) Reordenar: generar i escriure primer, marcar després; i fer servir la marca només per evitar feina repetida, no per a la correcció.

Anàlisi per punt de mort: abans de put_object: res escrit, el reintent ho fa tot. Entre put_object i marcar: el PDF existeix, la marca no; el reintent torna a generar el mateix PDF i l'escriu a la mateixa clau (S3 reemplaça l'objecte sencer; amb versionat en queda una versió més, inofensiva) i marca. Després de marcar: tot fet. En cap cas es perd la factura, i el pitjor resultat és un PDF regenerat. Escriure dues vegades és acceptable perquè l'operació és naturalment idempotent: mateix contingut determinista (el PDF no porta l'hora de generació; si la portés, caldria fixar-la al data_ms de l'esdeveniment) a la mateixa clau.

(c) Sí. Enviar un correu no és idempotent per naturalesa: enviar-lo dues vegades molesta l'Anna. Llavors la marca abans d'enviar és necessària per no duplicar, però deixa la finestra de pèrdua. La solució és la de 02-05 amb la passarel·la: fer servir un servei de correu que accepti una clau d'idempotència (molts l'ofereixen per missatge), de manera que es pugui enviar "una altra vegada" sense duplicar; o dividir-ho en dos passos, generar el PDF (idempotent, a S3) i encuar l'enviament en una cua amb deduplicació per id (SQS FIFO amb MessageDeduplicationId), on l'enviament es reintenta amb seguretat. Sense una d'aquestes dues coses, cal triar entre perdre o duplicar, i per a un correu es prefereix duplicar.

Exercici 2.

(a) Fotos: 4 200 productes, objectes immutables, un any de TTL; després de l'escalfament, cada punt de presència té totes les miniatures: hit ratio > 98 % (els misses són només el primer accés a cada objecte a cada PoP i les fotos noves). Egress des d'S3: 6 M × 180 KB ≈ 1,08 TB/dia sense CDN; amb un 98 % de hits, ≈ 22 GB/dia des d'S3 (més l'egress de la CDN cap a l'usuari, que sol ser molt més barat o inclòs). Fitxes: max-age=60 i 4 200 productes × 4 mercats = 16 800 variants; 6 M vistes/dia són 70 per segon, repartides en 16 800 claus: de mitjana cada clau es demana cada 4 minuts, així que a la majoria de PoP la fitxa ha caducat quan es torna a demanar; hit ratio potser del 30-60 % (millor per als productes populars, pitjor per a la cua llarga). stale-while-revalidate=300 fa pujar molt aquest ratio (serveix la caducada i refresca en segon pla), a canvi de fins a 5 minuts d'obsolescència. Egress des de Kong: 6 M × 4 KB = 24 GB/dia sense CDN; amb un 50 %, 12 GB. La foto domina: la CDN elimina el 98 % de ~1,1 TB diaris; per a la fitxa, el benefici és de latència i de càrrega a cataleg més que d'egress.

(b) Si el disseny és correcte (la foto nova té un ETag nou i la web referencia ?v=<etag nou>), el que ha fallat és que la fitxa que conté l'URL de la foto està desada a la memòria cau: els clients que reben una fitxa desada (fins a 60 s, o fins a 5 minuts amb stale-while-revalidate) reben l'URL antiga, que continua apuntant a un objecte immutable i vàlid, la foto antiga. No és una fallada de la foto sinó del TTL de la fitxa, i és el comportament esperat: "alguns clients durant uns minuts". Si el problema durés hores, la causa seria una altra: la web referenciant la foto sense ?v= (sobreescriptura de clau, l'error de 04-03) o el consumidor d'estoc.actualitzat invalidant Redis però no la CDN (04-05 advertia d'invalidar a totes les capes).

(c) Amb "Hola, Anna" al cos de la fitxa, la resposta ja no és igual per a tots els usuaris d'un mercat: o es marca private (i es perd la memòria cau a la CDN: el hit ratio de la fitxa cau a 0 i cataleg rep els 70 req/s sencers) o, pitjor, es desa per mercat i el Marc veu "Hola, Anna". L'alternativa: la fitxa continua sent pública i per mercat, i la personalització es fa al client (el navegador ja té el nom al JWT o a la sessió i el pinta) o amb una segona crida petita i private (/api/v1/jo) que la CDN mai no desa. És el principi del Worker: separar el compartit desable del personal.

Exercici 3.

(a) Orquestrador propi a comandes. Volum alt i constant (≈ 150 €/mes només en transicions de Step Functions, més les invocacions), al camí crític (cada transició afegeix desenes de ms al p99, i compromet l'SLO de 500 ms), durada de segons, i ja construït i provat amb Testcontainers. La visibilitat la donen les traces de 07-02 i la taula sagas.

(b) Step Functions. Desenes a l'any (cost menyspreable), durada de setmanes (esperes de 30 dies que un orquestrador propi hauria de gestionar amb estat persistit i temporitzadors: Step Functions té l'estat Wait amb dates i execucions de fins a un any), fora de qualsevol camí crític, i amb un valor de visibilitat enorme (veure en quin pas és la baixa de cada productor, qui l'ha aprovat, per què ha fallat la liquidació). Cada pas invoca les API dels serveis existents. El lock-in s'accepta perquè el flux és perifèric.

(c) Una funció disparada per temporitzador (o una cua amb retard), no Step Functions ni orquestrador. Centenars al dia amb un reintent cada 6 hores durant 3 dies és un patró de cua amb reintent diferit: SQS amb DelaySeconds (màxim 15 minuts, així que s'encadena) o, més simple, una taula cobraments_pendents amb seguent_intent i una Lambda programada cada 15 minuts que processa els vençuts amb la Idempotency-Key de 02-05 i publica pagament.confirmat o pagament.rebutjat en acabar. Step Functions amb Wait de 6 hores funcionaria, però és una màquina d'estats per al que és un bucle amb una data; el cost i la complexitat no es justifiquen, i la visibilitat la dona la taula.

Serverless i edge computing amplien l'espai de decisions de Quilòmetre Zero en dues direccions oposades a la del clúster en una regió. Amb FaaS, el proveïdor executa funcions efímeres en resposta a esdeveniments, escala de zero a milers i cobra per invocació i GB-segon; a canvi imposa arrencades en fred, límits de temps i memòria, absència d'estat i, sobretot, reintents que no controlem i que fan de la idempotència de 02-05 una obligació i no una bona pràctica. Amb aquest filtre, les miniatures de km0-fotos, les factures de pagament.confirmat, els webhooks de la passarel·la i les tasques programades surten dels serveis i passen a funcions definides amb SAM, amb DLQ, límit de concurrència i filtres que eviten bucles, mentre comandes, el WebSocket de 08-02, Flink i Spark es queden on eren. Els serveis serverless del voltant (cues, DynamoDB, API Gateway, Step Functions) completen el model, i la saga de 03-05 reescrita en Amazon States Language mostra amb precisió què es guanya (estat gestionat, reintents declaratius, visibilitat) i què es paga (latència, cost per transició, lock-in), cosa que deixa la saga de comanda a comandes i reserva Step Functions per als fluxos llargs i esporàdics. En l'altra direcció, l'edge acosta dades i còmput a qui els fa servir: la CDN serveix fotos immutables i fitxes per mercat amb TTL i invalidació dissenyats per tipus de contingut, el Worker verifica el JWT i decideix la clau de memòria cau sense tocar l'origen, l'agregador de la furgoneta converteix 36 posicions de túnel en una posició i un tram, i la parada del mercat continua venent sense connexió amb CRDT i reconciliació per autoritat, acceptant la partició de 03-02 en comptes de negar-la. El continu núvol-vora-dispositiu situa cada dada on l'equilibri és millor, i la seguretat a la vora parteix del fet que la vora pot mentir.

Amb això, totes les peces de Quilòmetre Zero són damunt la taula: des del tall dels bounded contexts de 08-01 fins a la memòria cau a València i la cua SQLite a la furgoneta. L'última lliçó les ajunta: l'arquitectura completa en un sol diagrama, el recorregut d'una comanda de l'Anna d'extrem a extrem amb tot el que deixa al seu pas, les decisions i els seus trade-offs revisitats com a ADR, els cinc símptomes de 01-06 amb la seva resolució, l'avaluació amb els criteris del curs, el que queda fora, el projecte que l'alumne pot construir al seu portàtil i la guia per continuar aprofundint. És el Projecte Final: Quilòmetre Zero d'Extrem a Extrem.