Quan les dades es reparteixen i repliquen entre diversos nodes, sorgeix una pregunta fonamental: podem garantir alhora que totes les lectures vegin la dada més recent, que el sistema respongui sempre i que toleri errors de xarxa? El Teorema CAP demostra que no: cal triar. Comprendre aquesta concessió és essencial per dissenyar l'emmagatzematge de dades de qualsevol sistema distribuït, i per triar correctament entre les desenes de bases de dades disponibles avui.

En aquesta lliçó estudiarem el Teorema CAP, el seu refinament PACELC, la diferència entre consistència forta i eventual, i classificarem les bases de dades més comunes segons les garanties que ofereixen.

1. Les tres propietats: C, A i P
2. L'enunciat del Teorema CAP
3. Per què P no és opcional a la pràctica
4. CP enfront d'AP: l'elecció real
5. PACELC: més enllà de CAP
6. Consistència forta enfront d'eventual
7. Taula de bases de dades segons CAP
8. Errors comuns i consells
9. Exercicis
10. Conclusió

El Teorema CAP, formulat per Eric Brewer, parla de tres propietats d'un sistema de dades distribuït:

Compte: la "Consistència" de CAP no és la "C" d'ACID. Aquí significa que totes les rèpliques coincideixen, no la integritat transaccional.

El teorema afirma:

En presència d'una partició de xarxa, un sistema distribuït només pot garantir dues de les tres propietats: o consistència, o disponibilitat, però no totes dues.

Imagina dos nodes replicats que deixen de comunicar-se (partició). Arriba una escriptura a un d'ells. Ara una lectura arriba a l'altre node, que no té aquesta escriptura. El sistema ha de decidir:

• Retornar la dada vella (manté la disponibilitat, sacrifica la consistència).
• Rebutjar la lectura o esperar (manté la consistència, sacrifica la disponibilitat).

No hi ha tercera opció. Per això CAP és una elecció, no un bufet.

Molta gent creu que pot triar "CA" (consistència i disponibilitat, renunciant a P). En un sistema realment distribuït això és una il·lusió: les particions de xarxa ocorren (cables que es tallen, commutadors que fallen, latències extremes). No pots garantir que mai no hi haurà una partició.

Per tant, en un sistema distribuït la P és obligatòria, i l'elecció real es redueix a:

• CP: davant una partició, prioritzo la consistència (puc deixar de respondre).
• AP: davant una partició, prioritzo la disponibilitat (puc retornar dades velles).

Un sistema "CA" només té sentit en una única màquina (una base de dades relacional clàssica en un sol servidor), on no hi ha xarxa per particionar.

La decisió depèn del cas de negoci:

La pregunta guia sempre és: què és pitjor per al meu negoci, donar una resposta incorrecta o no donar resposta?

CAP només parla de què passa durant una partició, que és una cosa poc freqüent. PACELC, formulat per Daniel Abadi, completa el quadre afegint què passa la resta del temps:

Partition: Availability o Consistency; Else (en operació normal): Latency o Consistency.

En altres paraules:

• Si hi ha Partició → tries entre A i C (com a CAP).
• Si no n'hi ha (Else) → tot i així tries entre Latència i Consistència, perquè garantir consistència forta entre rèpliques exigeix coordinació, que costa temps.

PACELC és més útil que CAP en el dia a dia, perquè la major part del temps no hi ha particions, i tot i així pagues un preu per la consistència.

La consistència eventual no significa "dades incorrectes per sempre", sinó que, si deixen d'arribar escriptures, totes les rèpliques acaben coincidint. Existeixen nivells intermedis útils, com ara read-your-own-writes (un usuari sempre veu els seus propis canvis).

L'interessant de sistemes com Cassandra és que ajustes la consistència per operació: escriptures crítiques amb QUORUM, lectures tolerants amb ONE. Si lectures i escriptures sumen més rèpliques que el total (W + R > N), obtens consistència forta sobre un sistema base AP.

Una classificació orientativa (moltes són configurables i poden moure's de categoria):

Pren aquesta taula com a guia, no com a dogma: la configuració concreta (factors de replicació, nivells de consistència) determina el comportament real.

• Confondre la C de CAP amb la C d'ACID: en CAP és "totes les rèpliques coincideixen"; en ACID és "integritat transaccional". No són el mateix.
• Creure que pots triar CA en un sistema distribuït: les particions ocorren; has de triar entre CP i AP.
• Aplicar consistència forta a tot: encareix la latència i redueix la disponibilitat sense necessitat. Reserva la forta per a dades crítiques.
• Ignorar PACELC: el cost de la consistència es paga també quan NO hi ha particions, en forma de latència.
• Triar base de dades per moda: tria segons les garanties que el teu cas de negoci necessita, no per la tecnologia més sonada.

1. Enuncia el Teorema CAP i explica per què, en un sistema distribuït real, l'elecció pràctica es redueix a CP o AP.
2. Per a cada cas, indica si triaries consistència forta (CP) o eventual (AP) i justifica-ho: (a) saldo d'un compte bancari, (b) nombre de "m'agrada" d'una publicació, (c) reserva d'una butaca en un cinema.
3. Explica què aporta PACELC enfront de CAP i què significa la classificació "PA/EL".

1. CAP diu que, davant una partició de xarxa, un sistema distribuït només pot garantir dues de les tres propietats (C, A, P). Com que les particions són inevitables en un sistema realment distribuït, P és obligatòria; per tant, l'elecció real és entre CP (sacrificar disponibilitat per mantenir consistència) i AP (sacrificar consistència per mantenir disponibilitat).

2. (a) CP/forta: un saldo incorrecte és inacceptable; millor un error que una dada errònia. (b) AP/eventual: un desfasament momentani en els "m'agrada" és irrellevant; prima respondre sempre. (c) CP/forta: no podem vendre la mateixa butaca dues vegades, així que la consistència mana.

3. PACELC afegeix què passa quan no hi ha partició: fins i tot llavors cal triar entre Latència i Consistència. "PA/EL" significa: davant una Partició prioritza la disponibilitat (A), i en operació normal (Else) prioritza la baixa Latència (a costa de consistència). És el perfil de sistemes com Cassandra.

Hem après que el Teorema CAP imposa una concessió inevitable: davant una partició de xarxa, cal triar entre consistència (CP) i disponibilitat (AP). PACELC refina la idea recordant que, fins i tot sense particions, paguem en latència per la consistència. L'elecció entre consistència forta i eventual, i la base de dades que la sustenta, han de respondre sempre a les necessitats del negoci: és pitjor una resposta incorrecta o cap resposta?

Amb aquesta lliçó tanquem el Mòdul 4, Arquitectures Distribuïdes i Microserveis. Has recorregut el camí complet: des dels fonaments dels sistemes distribuïts i les seves fal·làcies, passant per la descomposició en microserveis i bounded contexts, els mecanismes de comunicació, els patrons de resiliència, fins a les concessions de consistència de dades. Aquests coneixements et permeten dissenyar sistemes distribuïts robustos, conscients dels seus límits i adequats a cada problema de negoci.