Si hi ha una frase que resumeix l'ofici de l'arquitecte és aquesta: "depèn". Gairebé cap decisió arquitectònica no és bona o dolenta en absolut; és bona o dolenta per a un context concret i unes prioritats concretes. Dissenyar un sistema consisteix, en el fons, en una cadena de decisions on guanyar en un atribut gairebé sempre implica cedir en un altre. A aquests sacrificis deliberats els anomenem trade-offs o compromisos. En aquesta lliçó aprendràs què fa que una decisió sigui "arquitectònica", quins són els compromisos més universals (començant pel teorema CAP), com documentar decisions amb ADR i com avaluar arquitectures de manera estructurada amb el mètode ATAM.

1. Què és una decisió arquitectònica significativa
2. El concepte de trade-off
3. Trade-offs clàssics
4. El teorema CAP
5. Documentar decisions: els ADR
6. Avaluar l'arquitectura: el mètode ATAM

No tota decisió tècnica és arquitectònica. Una decisió és arquitectònicament significativa (allò que la literatura anomena Architecturally Significant Decision) quan compleix una o diverses d'aquestes característiques:

• Alt cost de canvi: revertir-la implicaria reescriure parts importants del sistema.
• Ampli abast: afecta diversos components, equips o atributs de qualitat.
• Impacte en atributs de qualitat: condiciona el rendiment, la seguretat, la disponibilitat, etc.
• Crea o elimina restriccions: obre o tanca opcions futures.

Exemples de decisions significatives: escollir entre monòlit i microserveis, escollir el model de consistència de dades, definir el mecanisme d'autenticació, seleccionar l'estil de comunicació entre serveis. Exemples de decisions no significatives: el nom d'una variable, el format d'indentació, quina llibreria d'utilitats menor usar.

Un trade-off és un intercanvi: per guanyar quelcom, cedeixes una altra cosa. En arquitectura, els recursos i els atributs de qualitat estan en tensió permanent.

Aquest diagrama Mermaid (graph LR, d'esquerra a dreta) mostra que una sola decisió —afegir una memòria cau— produeix simultàniament un efecte positiu (més rendiment) i dos de negatius (menys consistència i més complexitat). La lliçó clau és que tota decisió té conseqüències en diverses dimensions alhora, i la feina de l'arquitecte és fer-les explícites per decidir amb els ulls oberts.

La pregunta correcta mai no és "és bona aquesta opció?", sinó "què guanyo, què perdo, i compensa donades les meves prioritats?".

Aquests compromisos apareixen un cop i un altre en qualsevol sistema:

Vegem l'últim en detall:

La conclusió habitual: començar amb un monòlit ben estructurat (de vegades anomenat "monòlit modular") i extreure microserveis només quan el dolor concret ho justifiqui. Saltar directament a microserveis "perquè és el modern" és un error costós molt freqüent.

El teorema CAP, formulat per Eric Brewer, és el trade-off més famós dels sistemes distribuïts. Afirma que un sistema distribuït no pot garantir les tres propietats següents simultàniament, només dues:

• C — Consistència (Consistency): tota lectura rep la dada més recent o un error.
• A — Disponibilitat (Availability): tota petició rep una resposta (encara que no sigui la dada més recent).
• P — Tolerància a particions (Partition tolerance): el sistema segueix funcionant encara que es perdi la comunicació entre nodes.

La clau que molts passen per alt: en un sistema distribuït real, les particions de xarxa passen, no són opcionals. Per tant, la P és obligatòria, i l'elecció real és entre C i A quan hi ha una partició.

Aquest diagrama Mermaid il·lustra que el dilema CAP només es manifesta durant una partició. Quan no hi ha partició, un sistema pot oferir consistència i disponibilitat. Quan n'hi ha, ha d'escollir: un sistema CP prefereix rebutjar peticions abans que retornar una dada incorrecta (típic en banca); un sistema AP prefereix seguir responent encara que la dada pugui estar desactualitzada (típic en xarxes socials o catàlegs).

Un matís important: a la pràctica, la consistència no és binària. Molts sistemes usen consistència eventual, on les dades convergeixen al valor correcte després d'un breu període. El model PACELC estén CAP per considerar també el trade-off entre latència i consistència quan no hi ha particions.

Una decisió arquitectònica que només viu al cap de qui la va prendre està perduda. Els ADR (Architecture Decision Records, registres de decisions arquitectòniques) són documents breus que capturen una decisió i, sobretot, el seu perquè. Popularitzats per Michael Nygard, avui són una pràctica estàndard.

Un ADR típic té aquesta estructura:

Aquest ADR està escrit en Markdown i segueix el format de Nygard. Les seccions clau són: Estat (proposta, acceptada, obsoleta, substituïda), Context (el problema i les forces en joc), Decisió (què es decideix, en present i de manera afirmativa) i Conseqüències (els trade-offs, tant bons com dolents, escrits honestament). El més valuós és la secció de Conseqüències negatives: documentar allò que sacrifiquem evita que en el futur algú "redescobreixi" el problema i qüestioni la decisió sense entendre per què es va prendre. Els ADR es guarden versionats al costat del codi (per exemple, en una carpeta docs/adr/).

Com saber si una arquitectura proposada és adequada abans de construir-la? L'ATAM (Architecture Tradeoff Analysis Method), desenvolupat pel SEI, és un mètode estructurat per avaluar arquitectures analitzant precisament els seus trade-offs davant dels atributs de qualitat prioritaris.

Passos essencials de l'ATAM (simplificats):

1. Presentar el mètode als participants (negoci i tècnics).
2. Presentar els business drivers: objectius de negoci i atributs de qualitat prioritaris.
3. Presentar l'arquitectura proposada.
4. Identificar enfocaments arquitectònics (patrons i tàctiques usats).
5. Construir l'arbre d'utilitat (utility tree): es descomponen els atributs de qualitat en escenaris concrets, prioritzats per importància i per risc.
6. Analitzar els enfocaments davant dels escenaris prioritaris.
7. Identificar punts clau, en tres categories.
8. Presentar resultats.

En el pas 7, ATAM classifica les troballes en tres tipus molt útils fins i tot fora del mètode formal:

ATAM complet és un procés pesant, pensat per a sistemes crítics. Però la seva filosofia és aplicable sempre: avalua l'arquitectura contra escenaris de qualitat prioritzats i fes explícits els punts de compromís i els riscos. Fins i tot una versió lleugera, en una pissarra i un parell d'hores, aporta un valor enorme.

• Prendre decisions per moda. "Microserveis perquè està de moda" ignora el context. Decideix segons els teus atributs prioritaris, no segons el hype.
• No documentar el perquè. Sense ADR, les decisions es qüestionen eternament i es perd el coneixement en rotar l'equip.
• Ocultar les conseqüències negatives. Un bon ADR és honest sobre allò que se sacrifica. Maquillar els trade-offs porta a sorpreses doloroses.
• Creure que existeix la decisió "correcta". Gairebé tot és un compromís. Busca la decisió adequada per a les teves prioritats, no la perfecta.
• Consell: prioritza abans de decidir. Demana al negoci que ordeni els atributs de qualitat. Sense prioritats, no es poden resoldre els trade-offs.

Exercici 1. Per a un sistema de saldos bancaris i per a un feed d'una xarxa social, indica si escolliries CP o AP davant d'una partició de xarxa, i justifica-ho.

Exercici 2. Escriu un ADR breu (estat, context, decisió, conseqüències) per a la decisió "Adoptar una base de dades relacional única en lloc d'una base de dades per microservei" en una aplicació que encara és petita.

Exercici 3. En la decisió "introduir una memòria cau distribuïda davant de la base de dades", identifica un punt sensible, un punt de compromís i un risc segons la terminologia d'ATAM.

Solució 1. Saldos bancaris: CP. És preferible rebutjar una operació (no estar disponible momentàniament) abans que mostrar o permetre operar sobre un saldo incorrecte; la consistència és crítica. Feed de xarxa social: AP. És preferible seguir mostrant contingut (encara que falti l'última publicació) abans que deixar de respondre; la disponibilitat pesa més que veure la dada exacta a l'instant.

Solució 2. Exemple: Estat: Acceptada. Context: L'aplicació és petita, l'equip reduït i el domini encara no està estabilitzat; gestionar diverses bases de dades afegiria complexitat operativa i de consistència sense benefici clar. Decisió: Usar una única base de dades relacional compartida pels mòduls, mantenint-los lògicament separats (monòlit modular). Conseqüències: Positives: transaccions simples, consistència forta, menor cost operatiu, desenvolupament més ràpid. Negatives: acoblament a un únic esquema, possible coll d'ampolla en escalar i major esforç futur si es vol migrar a base de dades per servei.

Solució 3. Punt sensible: el temps d'expiració (TTL) de la memòria cau afecta decisivament el rendiment (quant s'aprofita la memòria cau). Punt de compromís: la memòria cau millora el rendiment però perjudica la consistència (dades potencialment obsoletes) i augmenta la complexitat. Risc: una estratègia d'invalidació incorrecta podria servir dades obsoletes als usuaris o, pitjor, provocar incoherències difícils de detectar.

Has après a reconèixer què fa que una decisió sigui arquitectònicament significativa, a raonar en termes de trade-offs, a manejar els compromisos clàssics i el teorema CAP, a documentar decisions amb ADR honestos i a avaluar arquitectures amb la filosofia d'ATAM. La idea que vertebra tot el capítol és que l'arquitectura és l'art d'escollir conscientment què sacrificar. Però de res no serveixen decisions brillants si ningú no les entén ni es poden comunicar a l'equip: en la següent i última lliçó del mòdul aprendràs a documentar l'arquitectura mitjançant vistes i el model C4, perquè les teves decisions es transmetin amb claredat.