La lliçó anterior va tancar el Mòdul 7 amb una pregunta pendent des del Mòdul 1: quan el monòlit Python+PostgreSQL es va partir en cataleg, comandes, inventari, pagaments, repartiment i analitica, què va fer que el resultat fos un sistema i no una col·lecció de sis programes que es criden per xarxa? Set mòduls han construït les peces (gRPC i Kafka, sagues i rèpliques, Cassandra i Redis, Spark i Flink, Keycloak i Vault, Prometheus i Kubernetes), però cap no ha explicat el criteri amb què es va decidir on tallar, quines dades posseeix cada servei, per què cataleg no consulta la base de dades d'inventari encara que tècnicament podria, ni què es paga per cadascuna d'aquestes decisions. Aquesta lliçó mira Quilòmetre Zero des de dalt, com a arquitectura de microserveis: què són (i què no), com es tracen les fronteres amb un Domain-Driven Design lleuger, com es resolen les consultes que travessen serveis quan cadascun és propietari de les seves dades, com es tria entre comunicació síncrona i asíncrona, com es migra des d'un monòlit sense aturar el negoci, com s'organitzen els equips i, sobretot, quan no convé fer-ho. Acaba amb el format que deixa escrites aquestes decisions: l'ADR. El temps real (08-02), el núvol (08-03) i serverless (08-04) queden per a les lliçons següents.

1. Què són els microserveis i què no
2. Les cinc característiques que els defineixen
3. Com tallar les fronteres: Domain-Driven Design lleuger
4. Errors de tall
5. Dades: una base de dades per servei i les seves conseqüències
6. CQRS: el panell de comandes d'un productor i la vista productes_vista
7. Comunicació: síncrona, asíncrona, APIs, gateway, BFF i mesh
8. Patrons de migració: avaluació del pla d'estrangulament
9. Organització: equips, Conway i plataforma interna
10. Quan no utilitzar microserveis i el retorn al monòlit modular
11. Registrar les decisions: l'ADR-001
12. Errors Comuns i Consells
13. Exercicis
14. Conclusió

A 01-02 es van presentar els "serveis/microserveis" com un model d'arquitectura més, al costat de client-servidor, capes i P2P, i es va remetre aquí. La definició operativa és aquesta: una arquitectura de microserveis descompon una aplicació en serveis petits, cadascun alineat amb una capacitat de negoci, que es despleguen de manera independent i es comuniquen per xarxa mitjançant contractes explícits. El que la distingeix no és la mida ni la tecnologia, sinó tres propietats que es reforcen mútuament: independència de desplegament, propietat de les dades i fronteres traçades pel negoci. Convé situar-la davant de les seves dues veïnes, amb les quals sovint es confon.

Dos aclariments importants. El primer: el monòlit modular no és l'enemic. El monòlit de Quilòmetre Zero a 01-06 ja tenia sis paquets per domini, i aquesta modularitat és el que va fer possible l'extracció; un monòlit amb mòduls ben separats i una sola base de dades és una arquitectura legítima i, per a moltes empreses, la millor. El segon: la SOA dels anys 2000 va fracassar no per la idea de serveis sinó per l'ESB (Enterprise Service Bus), que concentrava lògica, transformacions i orquestració en un component central que acabava sent un nou monòlit, propietat d'un equip d'integració que tothom esperava. Kafka, a Quilòmetre Zero, és deliberadament el contrari: un log que no transforma ni decideix res (02-04); tota la intel·ligència és als productors i consumidors.

Les cinc propietats següents són l'examen que cada servei de Quilòmetre Zero ha d'aprovar. Quan una falla, el sistema s'acosta al monòlit distribuït, la pitjor combinació possible: la complexitat de la xarxa sense la independència que la justificava.

Fixeu-vos que cap característica no parla de mida en línies de codi. "Micro" és una desafortunada tria de nom: la mida correcta és la que permet complir les cinc propietats amb un equip de mida raonable (la regla informal d'"un equip que s'alimenta amb dues pizzes"). comandes és probablement el servei més gran de Quilòmetre Zero, amb el seu orquestrador de sagues, la seva outbox i el seu repositori de Cassandra, i està bé així: partir-lo en comandes-creacio i comandes-consulta no afegiria independència, només crides de xarxa.

La pregunta més difícil d'una arquitectura de microserveis no és tècnica: és on tallar. Tallar malament produeix serveis que canvien sempre alhora, que es criden en cadena per a qualsevol operació i que comparteixen dades per la porta del darrere. L'eina conceptual més útil és el Domain-Driven Design (DDD), del qual aquí només prenem tres idees, suficients per traçar fronteres sense adoptar tota la seva metodologia.

Cada domini té un vocabulari que el negoci i el codi han de compartir paraula per paraula. Un producte al catàleg té nom, descripció, fotos i preu; per a l'inventari és una referència amb unitats disponibles i reservades en un mercat; per al repartiment és un paquet amb pes i necessitat de fred. És el mateix formatge-curat, però amb tres significats diferents, i forçar una única classe Producte amb els camps dels tres és el que produeix les taules amb 80 columnes del monòlit. El llenguatge ubic és el senyal per detectar fronteres: allà on una mateixa paraula canvia de significat, hi ha un límit de context.

Un bounded context (context delimitat) és l'àmbit en què un model i el seu llenguatge són vàlids i coherents. A dins, un terme significa una sola cosa; a fora, en pot significar una altra. Un microservei ben tallat coincideix amb un bounded context (o, de vegades, amb un conjunt petit d'ells que un equip posseeix junts). Els sis contextos de Quilòmetre Zero, amb el terme que dona nom al seu model central:

El mapa de contextos dibuixa les relacions entre bounded contexts i, per a cadascuna, qui mana sobre el contracte. Les relacions habituals són: client-proveïdor (el consumidor negocia el contracte amb el proveïdor: comandes demana a inventari un ReservarEstoc), conformista (el consumidor accepta el model del proveïdor tal com és: analitica consumeix els esdeveniments tal com arriben), capa anticorrupció (el consumidor tradueix el model aliè al seu per no contaminar-se: pagaments davant de la passarel·la externa) i llenguatge publicat (un contracte explícit i versionat que tothom coneix: els esdeveniments de comandes.esdeveniments amb el seu embolcall id_esdeveniment/tipus/versio/data_ms/origen/dades de 02-04).

Les fletxes contínues són crides síncrones i dibuixen les dependències en temps d'execució: si inventari cau, comandes no pot confirmar (però sí acceptar, com es va veure a 03-05). Les discontínues són esdeveniments i no creen dependència en temps d'execució: cataleg continua funcionant amb l'última vista que tingui encara que Kafka estigui caigut. Un mapa amb moltes fletxes contínues és el primer senyal d'un tall discutible.

Quan el llenguatge no n'hi ha prou per decidir, quatre heurístiques ajuden, i convé aplicar-les totes perquè de vegades es contradiuen:

1. Cohesió: el que canvia junt ha de viure junt. La reserva d'estoc i l'alliberament de la reserva són la mateixa capacitat; separar-les en dos serveis obligaria a coordinar cada canvi de regles en dos llocs.
2. Taxa de canvi: el que canvia a ritmes diferents convé separar-ho. pagaments canvia poc i amb auditoria; cataleg canvia diverses vegades al dia en campanya. Ajuntar-los imposa al catàleg el ritme de pagaments (símptoma 3 de 01-06).
3. Dades que canvien juntes en la mateixa transacció: si dues entitats necessiten actualitzar-se atòmicament amb freqüència, separar-les obliga a una saga per operació. Les unitats disponibles i les reservades d'una referència s'actualitzen sempre juntes: mateix servei, mateixa fila. La comanda i l'estoc s'actualitzen junts només en confirmar: aquí sí que compensa la saga perquè la resta del temps són independents.
4. Equips: una frontera de servei que travessa un equip genera dos serveis que es despleguen sempre alhora; una que agrupa dos equips genera baralles pel mateix codi. La frontera ha de coincidir amb la propietat (apartat 9).

Els tres errors més freqüents tenen nom propi, i val la pena reconèixer-los perquè tots tres semblen "més microserveis" i són el contrari.

Serveis anèmics o serveis-entitat. Tallar per taula: servei-productes, servei-clients, servei-comandes, cadascun un CRUD sense lògica. Tota operació de negoci ("confirmar comanda") travessa quatre o cinc d'ells en cadena síncrona, i la lògica acaba en un "servei orquestrador" que és el monòlit de sempre amb latència de xarxa. La prova: si el servei només té endpoints GET/POST/PUT/DELETE sobre un recurs i cap verb de negoci (reservar, cobrar, assignar), és una taula amb API, no una capacitat.

Nanoserveis. Tallar tan fi que el cost de la comunicació supera el de la funció: un servei per calcular l'IVA, un altre per formatar adreces. Cadascun necessita desplegament, monitoratge, contracte, guàrdia. Quilòmetre Zero va decidir a 01-06 que comandes inclou el càlcul de l'import i no un servei-preus, i a l'exercici 1 d'aquella lliçó que els cupons simples viuen a comandes, no en un servei-promocions.

Monòlit distribuït. El resultat de trencar qualsevol de les cinc característiques de l'apartat 2: serveis que comparteixen base de dades, que s'han de desplegar junts perquè comparteixen un model de dades o una llibreria interna amb lògica de negoci, o que es criden en cadena síncrona per a tot. Senyals mesurables: cada release toca més de tres repositoris; un canvi d'esquema d'una taula exigeix coordinar dos equips; la traça d'una petició senzilla (07-02) mostra més de cinc salts síncrons.

El principi "cada servei és propietari de les seves dades" (01-06, principi 1) és el que més costa d'acceptar perquè renuncia a l'eina més potent del monòlit: el JOIN. Al monòlit, el panell de la Formatgeria Montblanc es resolia amb una consulta:

Amb comandes a Cassandra (04-04), cataleg a PostgreSQL i repartiment al seu propi emmagatzematge, aquesta consulta ja no existeix. Hi ha tres maneres de reconstruir-la, i triar bé entre elles és una decisió d'arquitectura tan important com el tall dels serveis.

Les tres tècniques es recolzen en peces que el curs ja té: la composició usa els clients gRPC amb timeouts i circuit breaker (02-03, 07-04); les vistes materialitzades usen el consumidor idempotent i l'outbox de 02-05; i CQRS generalitza les vistes materialitzades.

Consistència eventual com a norma. A 03-05 la saga va substituir la transacció global per passos locals amb compensacions; la conseqüència per a les consultes és que, durant uns mil·lisegons o segons, la comanda P-2026-000125 existeix a comandes però encara no a la vista del productor. En una arquitectura de microserveis això no és un defecte que calgui corregir sinó l'estat normal, i el disseny ho assumeix: la interfície mostra "actualitzat fa 3 s", els tests accepten la finestra (07-06), i l'única pregunta que es fa per a cada dada és "quin retard tolera qui la llegeix?". La taula de 03-01 de models de consistència per dada és la que es revisa aquí: forta només per a l'estoc disponible i l'estat del cobrament; eventual per a tota la resta.

Marta Puig, de la Formatgeria Montblanc, obre el seu panell i espera veure les seves comandes dels últims 30 dies amb producte, unitats, estat i hora prevista de lliurament, filtrables per mercat i ordenables per data. Els fets viuen en tres serveis: la comanda i les seves línies a comandes, el nom del producte a cataleg, l'assignació i l'hora prevista a repartiment. Per composició a l'API caldria llegir totes les comandes (Cassandra no filtra per productor: la seva clau és el client, 04-04), consultar cataleg per cada producte i repartiment per cada comanda, i ordenar en memòria: inviable a partir d'uns centenars de comandes.

CQRS ho resol separant els dos costats:

• El costat d'ordres (commands) continua com està: comandes rep "crear comanda", executa la saga, escriu a Cassandra i publica a comandes.esdeveniments a través de l'outbox. És el model optimitzat per escriure correctament: validacions, idempotència, estats.
• El costat de consultes és un consumidor nou dins de comandes (o un servei de consulta propi, si creix) que se subscriu a comanda.creada, pagament.confirmat, pagament.rebutjat i als esdeveniments d'assignació de repartiment, i manté una taula comandes_per_productor a PostgreSQL amb exactament les columnes i l'índex que el panell necessita. És el model optimitzat per llegir ràpid.

Els dos costats comparteixen el nom comandes i l'equip, però no l'esquema ni la base de dades: l'escriptura no sap que la vista existeix, i la vista es pot reconstruir des de zero rellegint el tòpic des del principi (la retenció de Kafka de 02-04 és el que ho permet), cosa que també és la manera d'afegir una columna nova al panell sense migració.

El mateix patró, en la seva forma més simple, és el que cataleg usa per saber si un producte està disponible sense consultar inventari. A 04-05 l'esdeveniment estoc.actualitzat invalidava la memòria cau de Redis; aquí, a més, alimenta una taula desnormalitzada a la base de dades de cataleg, de manera que la fitxa del producte i els llistats filtrables per disponibilitat se serveixen amb una sola consulta local.

Explicació de les decisions que el codi conté:

• La fila de productes_vista la crea cataleg quan el productor publica el producte (amb disponible = FALSE); la projecció només l'actualitza. Si arriba un esdeveniment d'estoc d'un producte encara no publicat, l'UPDATE no afecta cap fila i s'ignora sense error: no és cap problema perquè, quan es publiqui, cataleg demanarà l'estoc inicial per ConsultarEstoc (02-03).
• versio_estoc < data_ms és la defensa contra el desordre: amb 6 particions a comandes.esdeveniments i clau = id de comanda, dos esdeveniments del mateix producte poden anar a particions diferents i arribar invertits. Sense aquesta condició, un esdeveniment vell trepitjaria un de nou. És el mateix raonament del SeguimentRepartidor de 01-05.
• El commit de l'offset va després de la transacció: si el procés mor a mig camí, l'esdeveniment es reprocessa i missatges_processats el descarta.
• unitats_aprox porta "aprox" al nom a propòsit: és una decisió de llenguatge ubic. Ningú a cataleg no ha d'usar aquest número per decidir si es pot vendre; això és ReservarEstoc a inventari amb consistència forta.

L'altra meitat de "propietari de les seves dades" és que la resta del codi no pugui saltar-se la frontera. Dins d'un servei Python, la convenció de Quilòmetre Zero és que cada bounded context és un paquet amb un únic mòdul públic, api.py, i tota la resta privada. Qui importi serveis.inventari.repositori des de comandes està cometent el mateix error que un JOIN creuat.

El servidor gRPC de 02-03 (ReservarEstoc, ConsultarEstoc) no fa res més que traduir missatges protobuf a aquestes tres funcions, i el ServeiInterceptor de 06-04 decideix qui pot cridar cadascuna. L'avantatge de tenir el context com a paquet amb API és que durant la migració (apartat 8) el monòlit va poder importar serveis.inventari.api en procés abans que existís el servei remot, i el canvi a gRPC no va tocar els que el cridaven.

El Mòdul 2 va donar les eines (gRPC a 02-03, Kafka i RabbitMQ a 02-04, patrons asíncrons a 02-05). El que correspon a aquesta lliçó és el criteri per triar, que es resumeix en una pregunta: el que crida necessita la resposta per continuar, i la necessita ara?

La regla pràctica de Quilòmetre Zero, fixada a l'exercici 2 de 01-06 i confirmada aquí: síncron només quan la resposta governa la decisió següent; tota la resta, esdeveniments. Cada crida síncrona afegeix una dependència de disponibilitat (la disponibilitat de la cadena és el producte de la de les seves baules) i de latència (la suma), i per això el mapa de contextos de l'apartat 3 només té dues fletxes contínues entre serveis.

No totes les interfícies són iguals. Una API pública (la que consumeix el navegador de l'Anna o l'app de repartidors, i en el futur tercers) és un compromís a llarg termini: es versiona, es documenta (OpenAPI), es protegeix al gateway, es limita per taxa i es manté compatible durant mesos. Una API interna (gRPC entre comandes i inventari) té pocs consumidors coneguts, canvia amb més llibertat i la seva compatibilitat es verifica amb les proves de contracte de 07-06. Confondre-les porta o a exposar detalls interns (l'id_reserva no li interessa a l'Anna) o a burocratitzar canvis interns.

Tota API pública canvia. La disciplina té dos nivells. Els canvis compatibles (afegir un camp opcional a la resposta, afegir un endpoint, acceptar un paràmetre nou amb valor per defecte) no necessiten versió nova: el client antic ignora el que no coneix. Els canvis incompatibles (canviar el nom d'un camp o treure'l, canviar-ne el tipus o la semàntica, canviar codis d'error) exigeixen una versió nova coexistint amb l'antiga durant un període anunciat. Quilòmetre Zero versiona a la ruta (/api/v1, /api/v2), que és l'opció més visible i la que Kong encamina sense ambigüitat (06-05).

Tres detalls importen més que el codi: la versió antiga es marca deprecated i s'anuncia una data de retirada (capçalera Sunset a la resposta i avís als consumidors registrats a Kong); es mesura qui continua usant v1 (la mètrica km0_http_requests_total{ruta="/api/v1/..."} de 07-01 diu quan es pot apagar); i el model intern mai no es manté en dues formes: v1 és una traducció del model actual. Per als esdeveniments, el versionat ja es va tractar a 02-05 (versio a l'embolcall, compatibilitat cap enrere a l'esquema).

El gateway de 06-05 és la vora de l'API pública: encaminament, JWT, rate limiting, X-Request-Id. Des del punt de vista arquitectònic, la seva funció és que els clients coneguin un domini i no sis serveis, i que les preocupacions transversals visquin en un sol lloc. El que no ha de fer és compondre respostes: quan un client necessita dades de diversos serveis en una pantalla, el BFF (Backend for Frontend) és el lloc, un per tipus de client, propietat de l'equip d'aquest client. La pantalla d'inici de l'app de repartidors (ruta del dia, propers paquets, incidències) és el cas previst a 06-05 i que el projecte final (08-05) situa a l'arquitectura.

A 06-04 es va veure el mesh com a manera de tenir mTLS sense codi, i a 07-05 com a sidecar que dona timeouts, reintents, outlier detection i telemetria RED per configuració; totes dues van remetre aquí la decisió. El criteri és de nombre i heterogeneïtat: amb sis serveis, tots en Python i amb serveis/comu/{resiliencia,metriques,traces}.py compartits, el mesh afegeix 1-2 ms per salt, memòria per sidecar i un pla de control per operar, a canvi de poca cosa que la llibreria comuna no doni ja. Compensa quan apareixen serveis en altres llenguatges (un recomanacions en Go o Java que no pot usar la llibreria Python), quan el nombre de serveis supera la desena i la uniformitat de polítiques esdevé un problema de govern, o quan la seguretat exigeix mTLS obligatori auditable (PeerAuthentication: STRICT) sense refiar-se que cada equip el configuri bé. Quilòmetre Zero l'adopta a l'arquitectura final (08-05) per aquesta última raó i perquè el cost d'operar-lo l'assumeix la plataforma interna (apartat 9), no els equips de producte.

A 01-06 es va fixar un pla d'estrangulament (strangler fig) en cinc fases. Ara, amb totes les peces construïdes, és el moment d'avaluar-lo fase per fase: què es va extreure, amb quin patró, i què se'n va aprendre. Abans, els quatre patrons que es van usar.

• Strangler fig: es col·loca una façana davant del monòlit (a Quilòmetre Zero, Kong), s'implementa una capacitat en un servei nou i s'hi redirigeix només aquella ruta; el monòlit perd responsabilitats fins a quedar buit. En cap moment hi ha dos sistemes sencers per mantenir.
• Anti-corruption layer (ACL): una capa de traducció entre el model nou i l'antic (o un d'extern), perquè el model del servei nou no hereti els defectes del monòlit. És la relació "capa anticorrupció" del mapa de contextos.
• Branch by abstraction: dins del monòlit, s'introdueix una interfície (InventariPort) amb dues implementacions, la local i la remota, seleccionable per configuració; es prova la remota amb un percentatge del trànsit i es retira la local quan està validada. Permet migrar sense branques de codi de llarga durada.
• Migració de dades amb doble escriptura i CDC: per moure una taula del monòlit a la base del servei nou sense aturada: primer es copia l'històric; després el monòlit escriu a totes dues (doble escriptura, amb la nova com a secundària) o, millor, un procés de Change Data Capture (Debezium llegint el WAL de PostgreSQL, el mateix WAL de 03-04) replica cada canvi al nou magatzem; es verifica la igualtat; s'inverteix la direcció (el servei nou és primari i el monòlit en llegeix); i s'apaga la còpia antiga.

Una observació sobre l'ordre: el pla de 01-06 va posar repartiment (fase 3) abans que comandes (fase 4) encara que el símptoma 3 (desplegaments) fos el que els equips sentien cada setmana. Va ser una decisió correcta per una raó que aleshores no es va fer explícita: repartiment va obligar a muntar Kafka, i sense Kafka la fase 4 no hauria pogut usar l'outbox ni les vistes materialitzades. L'ordre d'una migració el dicta la infraestructura que cada fase deixa a la següent, no només el dolor que alleuja.

La llei de Conway (1967) diu que un sistema reflecteix l'estructura de comunicació de l'organització que el construeix. És una llei empírica, però contrastada: si dos equips s'han de posar d'acord per a cada canvi, apareixerà una interfície entre els seus components; si un equip posseeix dos serveis, tendiran a acoblar-se perquè ningú no paga el cost de mantenir-los separats. La conseqüència pràctica, de vegades anomenada maniobra inversa de Conway, és que l'organització es dissenya per obtenir l'arquitectura desitjada: a 01-06 Quilòmetre Zero tenia quatre equips (catàleg i productors, comandes i pagaments, repartiment, dades), i les fronteres de servei van seguir aquestes línies. comandes i pagaments són dos serveis del mateix equip, i de fet són els dos que més es criden síncronament: Conway en acció.

Quatre regles d'organització que l'arquitectura necessita per sostenir-se:

1. Equips alineats a flux, propietaris d'una capacitat de negoci d'extrem a extrem (codi, dades, desplegament, guàrdia), en lloc d'equips per capa (frontend, backend, base de dades), que converteixen cada funcionalitat en un projecte de tres equips.
2. Un equip de plataforma interna que ofereix Kubernetes, el mesh, Kafka, l'observabilitat, el pipeline de desplegament i les llibreries serveis/comu/ com un producte amb usuaris (els equips de producte), amb documentació i SLO propis. Sense ell, cada equip reinventa la infraestructura, i la uniformitat que fa possible operar sis serveis es perd. A Quilòmetre Zero és l'antic equip de "dades" ampliat amb les persones que van muntar Kubernetes a 07-05.
3. Contractes com a acords entre equips: canviar inventari.proto o l'esquema d'estoc.actualitzat és una negociació amb els consumidors, verificada per les proves de contracte de 07-06, no una decisió unilateral.
4. Guàrdia per servei, no una guàrdia central: l'equip que desplega és el que rep l'alerta del seu SLO (07-01, 07-03). És el que alinea els incentius per fer serveis operables.

Quilòmetre Zero necessitava microserveis perquè tenia cinc símptomes mesurables i quatre equips. La majoria de les aplicacions no els tenen, i en elles una arquitectura de microserveis és un impost sense contrapartida: cada frontera de xarxa costa latència, fallades parcials, consistència eventual, contractes, desplegaments i guàrdies.

El retorn al monòlit modular no és un fracàs, i hi ha casos públics d'empreses que han reagrupat serveis que es cridaven en cadena per a tot. Els senyals per reagrupar dos serveis són els inversos dels de tallar: canvien sempre junts, tots els seus canvis exigeixen desplegar-los alhora, la traça de qualsevol operació els travessa sempre tots dos, o els posseeix el mateix equip i no tenen necessitats d'escalat diferents. A Quilòmetre Zero, si d'aquí a dos anys pagaments no tingués més lògica que l'adaptador a la passarel·la, seria candidat a tornar dins de comandes com a paquet amb el seu api.py: l'ACL i la idempotència es conservarien; la frontera de xarxa, no.

A 01-06 es va donar el consell de mantenir un registre de decisions d'arquitectura. Un ADR (Architecture Decision Record) és un document breu, numerat, immutable un cop acceptat (si la decisió canvia, s'escriu un altre ADR que el substitueix), amb quatre parts: context, decisió, alternatives considerades i conseqüències. El seu valor no és en la decisió, que sol conèixer-se, sinó en el context i les conseqüències, que són el que s'oblida i el que d'aquí a un any permetrà saber si la decisió continua sent vàlida. Aquest és el primer de Quilòmetre Zero, que el projecte final (08-05) completarà fins a l'ADR-006.

Els ADR viuen al repositori (km0/docs/adr/), es revisen en pull request com el codi i s'enllacen des del tiquet que va originar el canvi. Un ADR que només diu "usem Kafka" sense context ni conseqüències negatives no serveix: les conseqüències negatives són la part que més valor té.

• Tallar per taula o per capa tècnica. Produeix serveis-entitat i cadenes síncrones. Talla per capacitat de negoci; si el servei no té un verb de negoci a la seva API, replanteja'l.
• Compartir la base de dades "només per a lectures". És la manera més silenciosa de crear un monòlit distribuït: el primer ALTER TABLE trenca el veí. Vistes materialitzades per esdeveniments o composició a l'API; mai un SELECT creuat.
• Convertir cada consulta creuada en una crida síncrona. La disponibilitat es multiplica i la latència se suma. Si la consulta és freqüent i tolera segons de retard, és una projecció CQRS.
• Versionar l'API trencant l'anterior sense període de coexistència. Tota versió nova conviu amb l'antiga, marcada deprecated, amb data de retirada i amb una mètrica que digui qui la continua usant.
• Migrar en "big bang". Estrangular per rutes, començar per lectures, migrar dades amb CDC i verificació, i conservar sempre la marxa enrere (un canvi de ruta a Kong).
• Ignorar Conway. Fronteres de servei que no coincideixen amb equips s'acoblen o es barallen. Dissenya l'organització juntament amb l'arquitectura.
• Adoptar microserveis sense símptomes. Escriu els símptomes abans de tallar. Si no n'hi ha, el monòlit modular amb api.py per paquet és la resposta correcta, i és reversible.
• Consell: cada bounded context amb un sol mòdul públic; una prova d'arquitectura (amb import-linter o similar) que falli si algú importa un mòdul privat d'un altre context.
• Consell: escriu l'ADR abans de la decisió, no després: obliga a enumerar alternatives i conseqüències negatives quan encara es pot canviar d'idea.

Quilòmetre Zero vol afegir valoracions: l'Anna puntua d'1 a 5 cada producte que ha rebut i escriu un comentari; el productor respon; la fitxa del catàleg mostra la mitjana i els tres últims comentaris; el panell del productor mostra les seves valoracions pendents de resposta. Només es pot valorar un producte d'una comanda lliurada. Decideix: (a) és un bounded context propi o part de cataleg o de comandes? Justifica-ho amb les heurístiques de l'apartat 3. (b) Quina comunicació té amb els altres contextos (síncrona/asíncrona, i en quina direcció)? (c) Com obté la fitxa del catàleg la mitjana de valoracions sense cridar síncronament el nou context?

Un equip proposa aquesta implementació de "confirmar comanda": el BFF crida comandes, que crida clients (servei nou que exposa la taula d'usuaris) per validar l'adreça, després preus (nou, calcula l'import amb IVA) i inventari, pagaments i repartiment en seqüència, tot síncron; analitica consulta cada nit les taules de comandes amb un usuari de només lectura; i preus comparteix amb cataleg la llibreria km0-model amb les classes Producte i Preu. Enumera cada violació de les cinc característiques de l'apartat 2, anomena-la (servei-entitat, nanoservei, monòlit distribuït, base compartida...) i proposa la correcció amb les tècniques de la lliçó.

Escriu l'ADR-002, "Cassandra per a comandes", amb les quatre parts (context, decisió, alternatives rebutjades, conseqüències positives i negatives), recolzant-te en el que es va decidir a 03-02 i 04-04. Inclou-hi almenys tres conseqüències negatives.

Exercici 1.

(a) Context propi, valoracions. Llenguatge: "valoració", "mitjana", "resposta del productor" no existeixen en cap altre context, i "producte" aquí és només un identificador. Cohesió: les regles (una valoració per línia lliurada, moderació, resposta única) canvien juntes i no amb el catàleg. Taxa de canvi: és una funcionalitat nova que evolucionarà ràpid (moderació, fotos, filtres), diferent del ritme de comandes. Dades que canvien juntes: la valoració no s'escriu mai en la mateixa transacció que la comanda ni que la fitxa. Equip: encaixa en el de catàleg i productors, que pot posseir dos contextos. Posar-ho a cataleg acoblaria la moderació de comentaris als desplegaments del catàleg en campanya; a comandes contaminaria el context més crític amb lògica que no té res a veure amb la compra.

(b) Entrada: valoracions consumeix comanda.lliurada (esdeveniment de repartiment, asíncron) per saber quines línies es poden valorar: desa (client, comanda, producte, lliurat_en) a la seva pròpia base; així, en rebre "l'Anna valora formatge-curat de la P-2026-000124", ho comprova localment sense cridar comandes. Sortida: publica valoracio.creada i valoracio.resposta en un tòpic valoracions.esdeveniments. No hi ha cap crida síncrona entre serveis: l'única síncrona és del BFF/gateway a valoracions per crear i llistar.

(c) cataleg manté una projecció: consumeix valoracio.creada i actualitza a productes_vista (o una taula productes_valoracio) suma_punts, num_valoracions i una llista dels tres últims comentaris (JSON). La mitjana es calcula en llegir (suma/num) i tolera segons de retard. Amb el consumidor idempotent, una valoració reprocessada no compta dues vegades. És exactament la vista productes_vista de l'apartat 6 amb una altra font.

Exercici 2.

Exercici 3. Un ADR-002 acceptable:

• Context. Les comandes creixen 1,2 M al mes en campanya; el patró d'accés és "comandes d'un client per data" i "comanda per id", sense consultes ad hoc; s'exigeix disponibilitat per acceptar comandes fins i tot amb un node caigut o una partició (03-02: comandes tria disponibilitat); PostgreSQL amb Patroni té un primari únic que limita l'escriptura i el failover del qual (30 s) suposaria rebutjar comandes en campanya.
• Decisió. km0_comandes a Cassandra, 3 nodes, RF=3, taules comandes_per_client i comandes_per_id (desnormalitzades per consulta), escriptures amb QUORUM i lectures amb LOCAL_QUORUM per a l'estat de la comanda i ONE per a llistats; taula sagas al mateix keyspace.
• Alternatives rebutjades. PostgreSQL particionat per client amb Citus (manté SQL però introdueix un coordinador i transaccions distribuïdes que el patró d'accés no necessita); MongoDB (els documents hi encaixen, però el model de rèplica amb primari únic té el mateix problema de failover); mantenir PostgreSQL i acceptar els 30 s d'indisponibilitat (rebutjada pel símptoma 1: els pics coincideixen amb quan més fa mal).
• Conseqüències. (+) Escriptura lineal amb nodes; sense failover de primari; tolera un node caigut sense rebutjar comandes. (−) Sense JOIN ni consultes ad hoc: cada pregunta nova exigeix una taula nova o una vista CQRS (el panell del productor de l'apartat 6). (−) Consistència ajustable que el codi ha de triar a cada operació: un error de nivell és un bug silenciós. (−) Nova tecnologia per operar: compactacions, reparacions, snapshots (07-03), formació de l'equip. (−) Les transaccions lleugeres (Paxos) són cares: per això l'estoc no va aquí (ADR-001).

Una arquitectura de microserveis és un sistema, i no una col·lecció de serveis, quan cada servei compleix cinc propietats: representa una capacitat de negoci, és propietari de les seves dades, es desplega sol, el posseeix un equip i les seves fallades no es propaguen. Les fronteres es tracen allà on el llenguatge canvia de significat (bounded contexts), guiades per la cohesió, la taxa de canvi, les dades que canvien juntes i els equips, i el mapa de contextos de Quilòmetre Zero mostra el resultat: només dues fletxes síncrones (comandes → inventari, comandes → pagaments) i tota la resta per esdeveniments. Renunciar al JOIN obliga a compondre a l'API, a mantenir vistes materialitzades per esdeveniments o a separar formalment escriptura i lectura amb CQRS, com el panell de la Formatgeria Montblanc i la taula productes_vista, amb la consistència eventual com a estat normal i no com a defecte. La comunicació es tria cas per cas (síncrona només quan la resposta governa la decisió següent), les APIs públiques es versionen amb coexistència i mètriques d'ús, el gateway i el BFF separen el transversal de l'específic de cada client, i el mesh compensa quan l'heterogeneïtat o l'exigència de mTLS obligatori superen el que una llibreria comuna pot donar. El pla d'estrangulament de 01-06 s'ha revisat fase per fase (strangler fig, ACL, branch by abstraction, CDC), la llei de Conway explica per què l'organització i l'arquitectura s'han de dissenyar juntes, la taula de senyals diu quan el monòlit modular és la resposta correcta, i l'ADR-001 deixa escrit per què inventari va sortir del monòlit i què es paga per això.

Queda una peça de la plataforma que aquest mapa només ha anomenat: la fletxa discontínua repartiment.posicions acaba a Kafka, però l'Anna no llegeix Kafka. Entre el tòpic i la seva pantalla hi ha un últim tram amb regles pròpies (navegadors, mòbils, dispositius en xarxes dolentes, milers de connexions obertes), i aquest tram, amb MQTT i WebSockets que 02-01 va deixar presentats, és la lliçó següent: Sistemes de Missatgeria en Temps Real.