A 01-06 vam obrir un monòlit Python amb una base de dades PostgreSQL, un desplegament de dimarts i dijous i cinc símptomes que l'empenyien a canviar, i vam dibuixar una arquitectura objectiu amb una taula que remetia cada component a una lliçó futura. Trenta-vuit lliçons després, totes aquelles caselles estan construïdes: gRPC i Kafka, sagues i rèpliques, Cassandra i Redis, Spark i Flink, Keycloak i Vault, Prometheus i Kubernetes, MQTT i WebSockets, Terraform i Lambda, la CDN i la cua SQLite de la furgoneta. Aquesta última lliçó no afegeix cap peça nova: ajunta les que hi ha. Primer l'arquitectura completa en un sol diagrama i la taula de 01-06 tancada; després el recorregut d'una comanda de l'Anna des del seu navegador fins a la factura a S3, amb tot el que deixa al seu pas en traces, mètriques i auditoria; després les sis decisions d'arquitectura com a ADR, amb les seves alternatives rebutjades i les seves conseqüències; els cinc símptomes de 01-06 amb la seva resolució; l'avaluació de la plataforma amb els criteris del mateix curs (fal·làcies, consistència per dada, SLO, RPO/RTO, controls de seguretat); el que queda fora; el projecte que l'alumne pot construir al seu portàtil amb fites verificables; i una guia per continuar aprofundint. Els exercicis són d'integració: incorporar un domini nou, analitzar un incident d'extrem a extrem i retallar l'arquitectura per a tres persones. La conclusió tanca el curs.

1. L'arquitectura final de Quilòmetre Zero
2. La taula de 01-06, tancada
3. El recorregut d'una comanda de l'Anna d'extrem a extrem
4. El que la comanda deixa al seu pas: traces, mètriques i auditoria
5. Les decisions d'arquitectura com a ADR
6. Els cinc símptomes de 01-06, revisitats
7. Avaluació amb els criteris del curs
8. El que queda fora i passos següents
9. El projecte: Quilòmetre Zero reduït en docker-compose
10. Guia d'estudi
11. Errors Comuns i Consells
12. Exercicis
13. Conclusió

El diagrama té una peça que fins ara només estava promesa: el BFF de l'app de repartidors, anunciat a 06-05 i situat a 08-01. És un servei petit, propietat de l'equip de repartiment, darrere de Kong, que compon la pantalla d'inici de l'app (ruta del dia de repartiment, estat de les comandes d'aquesta ruta de comandes, noms i fotos dels productes de cataleg) en una sola resposta, amb crides en paral·lel, timeouts curts i degradació (si cataleg no respon, la ruta es mostra sense fotos). No té base de dades: és composició a l'API (08-01, apartat 5), justificada perquè l'app fa poques crides, les dades són petites i necessita frescor.

La taula de 01-06 era una promesa: cada component, la lliçó on es construiria. Aquesta és la mateixa taula, tancada, amb el que finalment es va construir i el fitxer o el nom que ho materialitza a km0/.

L'Anna, a València, compra dos formatge-curat de la Formatgeria Montblanc i un vi-crianca del Celler Roure Alt. La comanda és P-2026-000125. Aquest és el recorregut complet, amb la lliçó en què es va construir cada pas.

Cinc observacions sobre el diagrama que resumeixen el curs:

1. Només dues crides síncrones entre serveis (passos 9 i 12), totes dues amb timeout, circuit breaker i mTLS, i totes dues perquè la seva resposta governa la decisió següent (08-01). Tota la resta són esdeveniments.
2. Cap transacció no creua serveis. La comanda es crea a Cassandra, la reserva a RDS i el cobrament a la passarel·la com a transaccions locals; la saga les encadena i compensa (03-05); l'outbox garanteix que els esdeveniments surten si i només si la transacció local es confirma (02-05).
3. La idempotència apareix quatre vegades: la Idempotency-Key de l'Anna a Kong/comandes (un doble clic no crea dues comandes), l'id_reserva a inventari, la clau cobrament-<comanda> cap a la passarel·la, i l'id_esdeveniment a cada consumidor. Un reintent en qualsevol punt és segur.
4. L'Anna rep la resposta al pas 17, abans que existeixi la vista del catàleg, l'assignació de repartiment o la factura. El que veu després (posició de la furgoneta, factura a la seva àrea personal) arriba per camins asíncrons amb segons de retard, que és l'estat normal (08-01).
5. La vora i el gateway fan la seva feina abans que res arribi als serveis: el JWT es verifica tres vegades (Worker, Kong, servei), el rate limiting protegeix comandes, i la fitxa del producte ni tan sols ha arribat a la regió.

Una comanda no només produeix estat; produeix evidència. El que queda després de P-2026-000125:

La prova que l'observabilitat està ben feta és que amb el comanda_id es pot reconstruir tot: dels logs al trace_id, de la traça a cada servei i la seva latència, de la mètrica a si aquesta comanda va ser una de les que van trencar l'SLO, de l'esdeveniment al llac al que analitica va calcular, de l'auditoria a qui ho va fer. És el que l'exercici 2 posa a prova.

A 08-01 es va escriure l'ADR-001 complet. Aquestes són les sis decisions estructurals de Quilòmetre Zero en format resumit: cadascuna amb l'alternativa que es va rebutjar i la conseqüència negativa que es va acceptar, que és la part que d'aquí a un any permetrà saber si continua sent vàlida.

Cada ADR és a km0/docs/adr/ADR-00N-*.md, amb el format complet de 08-01. Fixeu-vos que tres de les sis decisions (002, 003, 006) rebutgen explícitament una opció "més moderna" o "més gestionada": l'arquitectura no és la suma de les millors tecnologies sinó de les decisions que responen a un símptoma amb un cost conegut.

Un bon curs deixa criteris, no només tècniques. Aquests són els cinc amb què Quilòmetre Zero s'avalua a si mateixa, i amb què l'alumne pot avaluar qualsevol altra plataforma.

La lliçó d'aquesta taula és que "forta" apareix dues vegades i "eventual" sis: la consistència forta es paga i es reserva per al que de debò la necessita.

Cap arquitectura no està acabada; aquesta té cinc fronts oberts, cadascun amb el mòdul del curs que dona les eines per abordar-lo:

1. Multiregió activa-activa. Avui hi ha pilot light (07-03, 08-03): la regió secundària triga 1-2 hores a servir. Passar a activa-activa exigiria decidir el model d'escriptura per dada: km0_comandes a Cassandra multi-DC (LOCAL_QUORUM per regió, 04-04) és natural; l'estoc (inventari) no ho és, i obligaria a particionar l'autoritat per mercat (Girona i Lleida escriuen a eu-west-1, València a eu-central-1) amb el model multilíder de 03-04 per als mercats repartits. És un projecte de mesos i l'ADR-007 pendent.
2. Event sourcing complet. Avui els esdeveniments són notificacions de canvis d'estat que es desen a part (i per sempre al llac). L'event sourcing faria dels esdeveniments la font de veritat de comandes: l'estat es reconstrueix reproduint comanda.creada, pagament.confirmat, ... Es guanya auditoria perfecta i reconstrucció de qualsevol vista; es paga amb snapshots, versionat d'esdeveniments històrics i consultes sempre per projecció. CQRS (08-01) ja deixa el terreny preparat.
3. Data mesh. analitica és avui un equip central que ho consumeix tot. A mesura que creixen els dominis, cada equip passaria a publicar les seves dades com a producte (amb esquema, qualitat, SLA i propietari) i analitica a ser plataforma. És la llei de Conway (08-01) aplicada a les dades.
4. Plataforma interna com a producte. L'equip de plataforma de 08-01 existeix; el que falta és tractar-lo com a producte: un portal on un equip crea un servei nou amb el seu Deployment, els seus dashboards, les seves alertes, el seu pipeline i el seu ADR de plantilla en minuts (l'exercici 1 ho posa a prova).
5. Cost com a restricció de disseny. FinOps (08-03) mesura; el pas següent és que el cost entri a les decisions d'arquitectura com hi entra la latència: euros per comanda com a SLO, revisió trimestral dels serveis gestionats davant dels propis, i apagada automàtica de tot el que no serveixi trànsit.

El curs ha mostrat codi a cada lliçó; el projecte proposa construir una versió reduïda i funcional al portàtil, amb el que cap a docker-compose i sense núvol: cataleg, comandes, inventari, Kafka, PostgreSQL, Redis i Prometheus. pagaments se simula, repartiment i analitica són opcionals, i la resta de la plataforma (Keycloak, Kubernetes, Terraform, Lambda, CDN) queda fora de l'abast mínim. L'important no és la mida sinó que cada fita sigui verificable amb una ordre.

Cada fita ha d'acabar amb un ADR curt si es pren una decisió (per exemple, "PostgreSQL en comptes de Cassandra per a comandes a la versió reduïda: context, conseqüències") i amb les proves que la verifiquen a tests/. El resultat és un repositori que es pot ensenyar i del qual es pot parlar en una entrevista amb la mateixa precisió amb què aquest curs ha parlat de Quilòmetre Zero.

El curs ha estat un mapa; aquests són els territoris per continuar. Se citen obres i articles per títol i autor, sense enllaços: tots són fàcils de localitzar pel seu nom.

Llibres de referència

• Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017). El llibre que més s'assembla als Mòduls 2, 3 i 4 d'aquest curs, amb molta més profunditat: replicació, particionament, transaccions, consens, processament per lots i en flux. És la lectura següent natural.
• Andrew S. Tanenbaum i Maarten van Steen, Distributed Systems (3a ed., disponible gratuïtament pels autors). El text acadèmic clàssic: models, comunicació, sincronització, consistència i tolerància a fallades amb rigor formal. Complementa el Mòdul 1 i el 3.
• Sam Newman, Building Microservices (2a ed., O'Reilly, 2021) i Monolith to Microservices (2019). Tot el de 08-01 amb detall: fronteres, migració, proves, organització.
• Betsy Beyer et al. (eds.), Site Reliability Engineering: How Google Runs Production Systems i The Site Reliability Workbook. L'origen dels SLO, els pressupostos d'error, els postmortems i la guàrdia del Mòdul 7. Disponibles gratuïtament en línia per Google.
• Eric Evans, Domain-Driven Design (2003), i Vaughn Vernon, Implementing Domain-Driven Design (2013), per aprofundir en els bounded contexts de 08-01.
• Gregor Hohpe i Bobby Woolf, Enterprise Integration Patterns (2003): el catàleg de patrons de missatgeria dels quals 02-04 i 02-05 van prendre els noms.
• Neal Ford, Mark Richards et al., Software Architecture: The Hard Parts (2021): trade-offs de descomposició, dades distribuïdes i sagues, amb el mateix esperit d'ADR.

Articles fundacionals (tots localitzables per títol)

• Leslie Lamport, "Time, Clocks, and the Ordering of Events in a Distributed System" (1978): la base de 01-05. I "The Part-Time Parliament" (1998) i "Paxos Made Simple" (2001) per al consens.
• Diego Ongaro i John Ousterhout, "In Search of an Understandable Consensus Algorithm" (Raft, 2014): el que etcd i Kafka KRaft implementen (03-03).
• Giuseppe DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store" (2007): hashing consistent, quòrums, vector clocks i la tria de disponibilitat que Cassandra hereta (04-01, 04-04).
• Jeffrey Dean i Sanjay Ghemawat, "MapReduce: Simplified Data Processing on Large Clusters" (2004), i Sanjay Ghemawat et al., "The Google File System" (2003): 05-02 i 04-02.
• James C. Corbett et al., "Spanner: Google's Globally-Distributed Database" (2012): consistència forta a escala global amb rellotges acotats (TrueTime), el contrapunt a Dynamo.
• Jay Kreps, Neha Narkhede i Jun Rao, "Kafka: a Distributed Messaging System for Log Processing" (2011), i l'assaig de Jay Kreps "The Log: What every software engineer should know about real-time data's unifying abstraction" (2013): la idea del log com a columna vertebral (ADR-004).
• Hector Garcia-Molina i Kenneth Salem, "Sagas" (1987): l'article original de 03-05.
• Seth Gilbert i Nancy Lynch, "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" (2002), i Daniel Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design" (PACELC, 2012): 03-02.
• Marc Shapiro et al., "Conflict-free Replicated Data Types" (2011): els CRDT de 03-01 i 08-04.
• Peter Deutsch i James Gosling, les "Fallacies of Distributed Computing", i Peter Bailis et al., "Highly Available Transactions: Virtues and Limitations" (2013), per continuar amb les fal·làcies i els models d'aïllament.
• Tyler Akidau et al., "The Dataflow Model" (2015): temps d'esdeveniment, marques d'aigua i finestres de 05-04.

Pràctica

• Jepsen (Kyle Kingsbury): anàlisis públiques de com fallen bases de dades reals sota particions; la millor escola d'escepticisme sobre garanties anunciades.
• Els llibres de Michael Nygard, Release It! (2a ed., 2018), per als patrons d'estabilitat de 07-04 explicats a partir d'incidents reals.
• Construir el projecte de l'apartat 9 i, després, trencar-lo amb els experiments de 07-06.

• Presentar l'arquitectura com un diagrama sense decisions. El diagrama de l'apartat 1 val poc sense els ADR de l'apartat 5; el que s'aprèn d'una arquitectura són les seves alternatives rebutjades i les seves conseqüències acceptades.
• Avaluar per tecnologies i no per criteris. "Fa servir Kafka i Kubernetes" no diu si està ben dissenyada. Les taules de l'apartat 7 (fal·làcies, consistència per dada, SLO, RPO/RTO, qui pot fer què) sí.
• Començar el projecte per la infraestructura. Kubernetes, mesh i Terraform sense un servei a desplegar és l'error de "triar tecnologies abans que problemes" de 01-06. El projecte comença a F1 amb tres serveis i docker-compose.
• Creure que la plataforma està acabada. L'apartat 8 llista cinc fronts; una arquitectura sense llista de pendents és una que ningú no està mirant.
• Consell: en qualsevol sistema nou, comença per escriure els símptomes (01-06), la taula de consistència per dada (03-01) i els SLO (07-01) abans de dibuixar caixes. Són les tres pàgines que més decisions correctes produeixen.
• Consell: guarda aquest curs com a referència per lliçó: quan d'aquí a un any hagis de decidir entre orquestració i coreografia, o quant TTL posar en una CDN, la lliçó corresponent té la taula.

A 08-01 es va decidir que les valoracions són un bounded context propi amb comunicació per esdeveniments. Ara dissenya'l d'extrem a extrem aplicant tot el curs: (a) contracte d'esdeveniments que consumeix i produeix (amb l'embolcall de 02-04) i model de dades amb el seu model de consistència (03-01) i el seu emmagatzematge (Mòdul 4); (b) API pública a Kong amb autenticació i autorització (qui pot valorar què; 06-01, 06-05) i com arriba la mitjana a la fitxa desada per la CDN (08-04); (c) SLO, mètriques i alertes (07-01), i quines traces i auditoria deixa una valoració; (d) desplegament (07-05), RPO/RTO (07-03) i què caldria afegir a main.tf (08-03); (e) l'ADR-007 en format resumit (decisió, alternativa rebutjada, conseqüència).

Dissabte 19 de setembre, 18:42, Setmana del Formatge Artesà. Es dispara l'alerta "SLO de comandes: consum de pressupost d'error ×14 en 5 min". Dades disponibles:

• Prometheus: rate(km0_comandes_total{estat="rebutjada_estoc"}[5m]) passa de 0,3/s a 9/s a les 18:40; la latència p99 de POST /comandes baixa de 420 ms a 95 ms; km0_grpc_client_durada_segons{metode="ReservarEstoc"} p99 = 8 ms; km0_circuit_estat{dependencia="inventari"} = 0; lag del grup cataleg-projeccio = 0.
• Logs d'inventari (Loki): a partir de les 18:39:50, centenars de línies {"nivell":"warning","msg":"EstocInsuficient","producte":"formatge-curat","mercat":"girona","disponibles":0,"sollicitades":2,"request_id":...}.
• Logs de cataleg: {"nivell":"info","msg":"vista actualitzada","producte":"formatge-curat","mercat":"girona","aplicat":true} a les 18:39:48, i cap més després per a aquest producte.
• Traces: les comandes rebutjades tenen spans kong → comandes → inventari.ReservarEstoc (EstocInsuficient) de 90 ms; cap no arriba a pagaments.
• productes_vista a cataleg: formatge-curat / girona: disponible = true, unitats_aprox = 0, versio_estoc = 1758300000123.
• Auditoria: a les 18:39:45, {"qui":"mpuig","accio":"estoc.ajustar","recurs":"formatge-curat/girona","de":140,"a":0,"origen":"panell-productor"}.

(a) Reconstrueix la cadena causal completa. (b) És un incident de la plataforma, del producte o d'operació? Quina part del comportament és correcta i quina és un defecte? (c) Localitza el defecte exacte al codi de 08-01 (projeccio_estoc.py o productes_vista.sql) i corregeix-lo. (d) Escriu les tres accions del postmortem (07-03) i quin senyal hauria detectat el problema abans que l'SLO.

Una startup de tres persones vol llançar un marketplace com Quilòmetre Zero en un sol mercat, amb 20 productors, 300 comandes al dia i 6 repartidors. Tenen tres mesos i no poden operar Kubernetes ni Kafka. Fent servir la taula de "quan no fer servir microserveis" de 08-01 i el lock-in selectiu de 08-03, dissenya l'arquitectura mínima: (a) què es queda com a monòlit modular i amb quina estructura interna; (b) quines tres decisions de Quilòmetre Zero conservaries intactes perquè són barates i eviten errors irreversibles; (c) com resoldries el seguiment en temps real i les fotos sense Kafka, MQTT ni Lambda; (d) quins senyals mesurables indicarien que ha arribat el moment d'extreure el primer servei, i quin seria.

Exercici 1.

(a) Consumeix comanda.lliurada (publicat per repartiment a comandes.esdeveniments amb l'embolcall estàndard; dades: {comanda_id, client, linies: [{producte, productor}], lliurat_ms}) per saber què es pot valorar. Produeix en un tòpic nou valoracions.esdeveniments (3 particions, clau = producte, perquè les valoracions d'un producte arribin en ordre a la projecció): valoracio.creada {valoracio_id, client, comanda_id, producte, productor, punts, comentari, data_ms} i valoracio.resposta {valoracio_id, productor, resposta, data_ms}. Model: taula valorables (client, comanda_id, producte, lliurat_ms, valorat bool) i valoracions (id, client, producte, productor, punts, comentari, resposta, creada_en) en una base PostgreSQL pròpia km0_valoracions (RDS petita, sense Multi-AZ al principi): volum baix (una per línia lliurada), consultes relacionals (per producte, per productor, pendents de resposta), i la regla "una valoració per línia" exigeix una restricció UNIQUE (client, comanda_id, producte) amb consistència forta local. La mitjana a la fitxa és eventual (projecció a cataleg), i el panell del productor llegeix la seva pròpia base amb consistència forta.

(b) Rutes a Kong: POST /api/v1/valoracions (rol client), GET /api/v1/productes/{slug}/valoracions (pública, desable 60 s), POST /api/v1/valoracions/{id}/resposta (rol productor), GET /api/v1/productors/me/valoracions?pendents=true (rol productor). Autorització al servei: en crear, claims.sub ha de tenir una fila a valorables no valorada per a aquella comanda i producte (ABAC amb dada pròpia, sense cridar comandes); en respondre, claims.productor ha de coincidir amb valoracions.productor. Rate limiting específic (5 valoracions/minut per consumidor) contra l'abús. La mitjana arriba a la fitxa perquè cataleg consumeix valoracio.creada i manté suma_punts i num_valoracions a productes_vista (idempotent per id_esdeveniment); la fitxa continua sent public, max-age=60 per mercat, i la mitjana canvia amb fins a un minut de retard a la CDN, acceptable. Els tres últims comentaris se serveixen a la ruta pública de valoracions (desable, sense dades personals més enllà del nom de pila, que el client va consentir).

(c) SLO: 99,5 % de disponibilitat i p99 < 300 ms per crear (no és al camí de compra: SLO més lax que el de comandes). Mètriques: km0_valoracions_total{resultat}, latència per ruta, lag del consumidor de comanda.lliurada i del de cataleg sobre valoracions.esdeveniments. Alertes: consum de pressupost d'error, lag > 5 min (un lliurament que no es pot valorar), i taxa de no_autoritzat anòmala (abús). Traça: kong → valoracions POST → postgres, enllaçada al consumidor de cataleg per l'id_esdeveniment. Auditoria: valoracio.crear i valoracio.respondre a auditoria.esdeveniments (les respostes dels productors són contingut públic, i la moderació necessita saber qui ha escrit què).

(d) k8s/valoracions-deployment.yaml copiant la plantilla de comandes (2 rèpliques, sondes, resources, topologySpreadConstraints, HPA per CPU, NetworkPolicy que només permet entrada des de Kong i sortida al seu RDS i a Kafka, serviceAccountName amb IRSA sense permisos d'S3). RPO: minuts (còpies de seguretat d'RDS i PITR; la pèrdua de valoracions és tolerable però molesta); RTO: 1 hora (no bloqueja vendes). A main.tf: aws_db_instance.valoracions (db.t4g.small, sense multi_az), el seu grup de seguretat (5432 només des d'EKS), un mòdul IRSA sense polítiques d'S3, i el tòpic valoracions.esdeveniments gestionat amb el proveïdor kafka o creat pel pipeline.

(e) ADR-007: "valoracions com a bounded context propi amb PostgreSQL i comunicació exclusivament per esdeveniments". Alternativa rebutjada: dins de cataleg (acoblaria la moderació als desplegaments del catàleg en campanya i barrejaria dos llenguatges: "producte publicat" i "valoració"). Conseqüència acceptada: la fitxa mostra la mitjana amb fins a un minut de retard; un component més amb base de dades, dashboard i guàrdia (de l'equip de catàleg i productors); si repartiment deixa de publicar comanda.lliurada, ningú no pot valorar fins que es recuperi el lag (alerta).

Exercici 2.

(a) Cadena causal: 18:39:45, Marta Puig ajusta des del seu panell l'estoc de formatge-curat a Girona de 140 a 0 (probablement un error en introduir la dada, o una retirada real del producte). inventari aplica l'ajust i publica estoc.actualitzat {disponible: 0}. 18:39:48, cataleg rep l'esdeveniment i la projecció l'aplica (aplicat: true) → unitats_aprox = 0. Però disponible continua a true. A partir de les 18:39:50, els clients que veuen la fitxa (amb disponible = true) afegeixen formatge-curat al cistell i confirmen; comandes inicia la saga, inventari respon EstocInsuficient en 8 ms, la saga compensa i la comanda queda rebutjada_estoc. La latència p99 baixa (les comandes rebutjades no passen per la passarel·la), la taxa de rebuigs puja ×30 i el pressupost d'error es consumeix perquè rebutjada_estoc compta com a fallada de l'SLO de comandes.

(b) És un incident mixt. La saga, el circuit i la compensació funcionen correctament: cap comanda no s'ha cobrat sense estoc, cap reserva no ha quedat penjada. L'ajust de la Marta és una acció legítima de negoci (i l'auditoria la registra amb precisió). El defecte és a la plataforma: la fitxa del catàleg continua dient "disponible" amb 0 unitats, cosa que dirigeix centenars de clients a un rebuig segur. És un defecte de la projecció CQRS, no de la consistència eventual: el retard va ser de 3 segons, acceptable; el problema és que la dada projectada és incorrecta de manera permanent.

(c) A projeccio_estoc.py, aplicar calcula disp = d["disponible"] >= LLINDAR_DISPONIBLE amb LLINDAR_DISPONIBLE = 1: amb disponible = 0, disp = False, i l'UPDATE hauria d'haver posat disponible = FALSE... tret que la condició versio_estoc < %(v)s hagi fallat. Però el log diu aplicat: true, així que l'UPDATE va afectar la fila. Llavors el defecte no és aquí; mireu productes_vista.sql: disponible BOOLEAN NOT NULL DEFAULT FALSE i unitats_aprox s'actualitzen juntes al mateix UPDATE. La fila mostra unitats_aprox = 0 i disponible = true, cosa que només és possible si una altra ruta d'escriptura va posar disponible = true després: la ruta de publicació del producte pel productor (cataleg crea/actualitza la fila quan el productor edita la fitxa i, segons 08-01, "la fila la crea cataleg quan el productor publica el producte"). La Marta va editar la fitxa (potser el mateix ajust des del panell toca producte i estoc), i l'UPSERT de publicació sobreescriu disponible amb el seu valor per defecte o amb el valor que tenia la fitxa al formulari, sense respectar versio_estoc. El defecte és que dos camins escriuen la mateixa columna amb regles diferents: la correcció és que la publicació de la fitxa mai no escrigui disponible ni unitats_aprox (columnes propietat exclusiva de la projecció), és a dir, INSERT ... ON CONFLICT (slug, mercat) DO UPDATE SET nom = EXCLUDED.nom, preu_cents = EXCLUDED.preu_cents, productor = EXCLUDED.productor sense tocar les columnes d'estoc; i, com a xarxa de seguretat, un CHECK (NOT disponible OR unitats_aprox >= 1) a la taula que faria fallar l'escriptura incoherent en comptes de deixar-la passar. És el principi de 08-01 de "propietari de la dada" aplicat dins d'un servei, columna a columna.

(d) Postmortem sense culpa (07-03): 1. Corregir l'UPSERT de publicació i afegir el CHECK; prova d'integració (07-06) que publica la fitxa després d'un estoc.actualitzat a 0 i verifica disponible = false. 2. Afegir una confirmació al panell del productor per a ajustos d'estoc que canviïn més d'un 50 % ("Posar formatge-curat a Girona a 0 unitats? N'hi havia 140"), perquè l'auditoria mostra un salt improbable. 3. Separar a l'SLO de comandes els rebuigs per estoc (resultat de negoci correcte) dels errors de plataforma, o crear una alerta específica de "taxa de rebutjada_estoc per producte" amb llindar baix, perquè el símptoma s'atribueixi bé. El senyal que ho hauria detectat abans: una alerta de coherència a la projecció, count(productes_vista where disponible and unitats_aprox = 0) > 0, avaluada cada minut (una consulta barata), o la mètrica de Flink de 05-04 alertes_estoc per a formatge-curat a Girona, que es va disparar a les 18:39:50 cap a inventari.alertes i que la Marta va rebre per SSE (08-02) però que ningú no va correlacionar amb els rebuigs.

Exercici 3.

(a) Un monòlit modular en Python (FastAPI) amb una base de dades PostgreSQL gestionada (RDS o Cloud SQL amb còpies de seguretat automàtiques i PITR, sense Multi-AZ al principi), desplegat en un PaaS de contenidors (Cloud Run, App Runner, Fly.io, Render: 2 instàncies, autoescalat inclòs, TLS gestionat). Estructura interna: els sis paquets de 01-06 (cataleg, comandes, inventari, pagaments, repartiment, analitica) cadascun amb el seu api.py com a únic mòdul públic (08-01), esquemes de PostgreSQL separats per paquet (inventari.referencies, comandes.comandes) i una regla de lint (import-linter) que prohibeix importar mòduls privats d'un altre paquet i consultes SQL entre esquemes. La transacció de confirmar comanda és local (una sola base): reserva, comanda i registre del cobrament en una transacció, amb la crida a la passarel·la fora d'ella (cobrar primer amb Idempotency-Key, després confirmar en transacció; si falla la confirmació, reemborsar). Redis gestionat petit per a la memòria cau del catàleg i el limitador. Un sol repositori, un pipeline, docker-compose per a desenvolupament.

(b) Tres decisions barates que eviten errors irreversibles: 1. L'embolcall d'esdeveniments i una taula esdeveniments (outbox) des del primer dia, encara que el "bus" sigui la mateixa base de dades i el consumidor un procés del monòlit: quan arribi Kafka, els productors ja publiquen i els consumidors ja són idempotents; i el llac analític pot començar exportant aquesta taula a Parquet cada nit. 2. Idempotència a les API d'escriptura (Idempotency-Key en crear comanda, claus deterministes cap a la passarel·la): és el que a 02-05 i 08-04 evita cobraments i comandes duplicats, costa una taula, i no es pot afegir després sense migrar clients. 3. Observabilitat mínima amb SLO: logs JSON amb request_id, mètriques RED i un SLO escrit per crear comanda; sense això, no hi haurà dades per decidir quan extreure res (apartat d). I una quarta gratuïta: els ADR des del primer dia.

(c) Seguiment: 6 repartidors enviant posicions per HTTPS POST cada 10 s al monòlit (60 peticions/minut: res), desades en una taula repartiment.posicions amb retenció de 24 h (a aquest volum, PostgreSQL sobra), i els clients amb SSE o polling cada 5 s contra un endpoint que retorna l'última posició de la comanda (amb Cache-Control: max-age=4 perquè el PaaS o una CDN absorbeixi repeticions). Sense MQTT ni WebSockets: no hi ha volum que ho justifiqui, i SSE amb reconnexió automàtica cobreix l'experiència. Fotos: pujada per URL presignada a S3/GCS (04-03, es conserva) i miniatures generades al mateix monòlit en una tasca en segon pla (una cua simple a PostgreSQL amb SELECT ... FOR UPDATE SKIP LOCKED, processada per un worker del mateix desplegament), amb una CDN gratuïta o de baix cost davant del bucket amb claus immutables (08-04, es conserva perquè és gairebé gratis i evita l'egress).

(d) Senyals per extreure el primer servei, mesurables gràcies a (b)-3: el p99 de crear comanda es degrada quan puja el trànsit del catàleg (contenció a la mateixa base o CPU: símptoma 1); l'equip passa de 3 a 8-10 persones i els desplegaments del catàleg trenquen comandes (símptoma 3); el trànsit de lectura supera el que Redis + una rèplica de lectura de PostgreSQL absorbeixen; o la latència de la passarel·la comença a bloquejar connexions (símptoma 2). El primer a sortir, com a 01-06, és cataleg (només lectures, sense transaccions creuades, marxa enrere amb un canvi de ruta) o, si el símptoma dominant és el de la passarel·la, pagaments amb la seva ACL. Mai comandes i inventari primer: són els que exigeixen sagues, i les sagues es justifiquen només quan la frontera ja existeix per una altra raó. La regla de 08-01 es compleix a l'inrevés: tres persones sense símptomes és la fila exacta de la taula que diu "monòlit modular".

Quilòmetre Zero va començar com un monòlit Python amb una base de dades i cinc símptomes, i acaba com una plataforma que es pot dibuixar en un diagrama, recórrer amb una comanda, justificar amb sis ADR i avaluar amb els criteris que el mateix curs ha donat: les vuit fal·làcies assumides com a falses en punts concrets del disseny, una taula de consistència per dada on "forta" apareix dues vegades i "eventual" sis, SLO i RPO/RTO per component, i una taula de qui pot fer què des de l'Anna fins al Worker de la CDN. Els cinc símptomes de 01-06 tenen cadascun la seva resolució i la seva manera de verificar-la; les decisions tenen cadascuna la seva alternativa rebutjada i el seu preu; i el que queda fora està escrit, amb el mòdul que dona les eines per abordar-ho. El projecte proposat redueix tot això al que cap en un portàtil, amb deu fites que es comproven amb una ordre, i la guia d'estudi assenyala els llibres i articles on cada idea d'aquest curs té el seu origen i la seva profunditat.

El que l'alumne sap fer ara no és "fer servir Kafka" o "desplegar a Kubernetes", encara que també. És una cosa més duradora: davant d'un sistema que s'ha de repartir entre diverses màquines, sap escriure primer els símptomes i no les tecnologies; tallar fronteres on el llenguatge canvia de significat i no on hi ha una taula; triar per a cada dada el model de consistència que necessita i pagar només per aquest; fer que cada crida tingui timeout, cada missatge un identificador i cada consumidor sigui idempotent, perquè la xarxa fallarà; substituir la transacció global per una saga que compensa; posar la dada on la seva càrrega ho demana, de PostgreSQL a Cassandra, de Redis a S3, de la CDN a la cua SQLite d'una furgoneta; separar el que es calcula per lots del que no pot esperar; autenticar i autoritzar a cada frontera sense confiar en cap; mesurar amb SLO, observar amb traces, recuperar amb còpies de seguretat provades i assajar les fallades abans que passin; descriure la infraestructura com a codi i el cost com una mètrica; i deixar cada decisió escrita amb el seu context i les seves conseqüències, perquè qui vingui després pugui canviar-la amb coneixement.

Això és dissenyar arquitectures distribuïdes: no acumular peces, sinó saber en cadascuna què es guanya, què es perd i per què es va triar. Quilòmetre Zero ha estat l'excusa; el criteri és el que s'endú l'alumne. Gràcies per haver recorregut el curs fins aquí, i bona sort amb el següent sistema que s'hagi de repartir entre diverses màquines: ara ja sap per on començar.