Cos'è il teorema CAP e cosa significa davvero?

Il teorema CAP afferma che un sistema distribuito non può garantire simultaneamente consistenza, disponibilità e partition tolerance: quando una partizione di rete divide i nodi in gruppi che non si parlano più, la scelta reale è tra consistenza e disponibilità. La dimostrazione è di Seth Gilbert e Nancy Lynch, Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services, ACM SIGACT News, 2002, che formalizza la congettura di Eric Brewer a PODC 2000. La consistenza del CAP non è quella di ACID: è la consistenza atomica, o linearizzabilità, che richiede un ordine totale sulle operazioni tale per cui ogni lettura vede l'ultima scrittura completata come se il sistema fosse un singolo nodo. È la confusione più diffusa. La disponibilità richiede che ogni richiesta a un nodo funzionante riceva risposta. La partition tolerance è la capacità di operare quando messaggi tra nodi vengono persi, e non è opzionale in un sistema su più macchine collegate da una rete reale, dove le partizioni prima o poi accadono.

Cosa il teorema non dice: l'equivoco del "due su tre"

La lettura popolare "scegline due su tre" tratta le tre proprietà come opzioni permanenti di design, e su questo punto fraintende il teorema: la partition tolerance non è una scelta che si possa rifiutare. La scelta vera, come chiarisce Eric Brewer nel suo aggiornamento del 2012, CAP Twelve Years Later: How the "Rules" Have Changed, IEEE Computer, è tra C e A, ed è locale e temporanea: riguarda una singola operazione durante una singola partizione, non l'intero sistema per sempre. Finché la rete funziona raramente c'è ragione di rinunciare a C o ad A: un sistema che può riconoscere il ritardo di un messaggio le offre entrambe. Brewer descrive anche una fase di recupero dopo la partizione, in tre passi: rilevare che è iniziata, limitare alcune operazioni finché dura, e riconciliare gli stati divergenti quando la comunicazione riprende. PACELC di Daniel Abadi (2012) aggiunge che il compromesso non sparisce nemmeno senza partizioni: resta un trade-off tra latenza e consistenza, perché replicare in modo forte costa tempo di risposta.

Un esempio enterprise

Un rivenditore con magazzini in più regioni replica l'inventario su nodi geograficamente distanti. Quando un collegamento tra due data center cade, il nodo che riceve un ordine può scegliere: rifiutare la vendita finché non conferma la scorta con l'altro nodo, sacrificando disponibilità, oppure accettare l'ordine sul dato locale, forse disallineato, sacrificando consistenza e rischiando una vendita in eccesso da riconciliare dopo. Nessuna delle due risposte è quella "giusta" in assoluto: dipende da cosa costa di più al business. La stessa architettura che tiene un database per servizio affronta questa decisione a ogni confine di rete tra i servizi, e chi disegna un flusso guidato da eventi tramite architettura event-driven la eredita nella scelta tra pubblicare subito o attendere una conferma di scrittura.

Perché conta per chi decide

Il teorema CAP è la ragione per cui due database entrambi definiti "enterprise-grade" si comportano diversamente durante un guasto di rete, e per cui un fornitore non può promettere "sempre disponibile e sempre consistente" senza tacere una condizione. Chiedere esplicitamente cosa succede al sistema durante una partizione, e quale proprietà viene sacrificata, separa una scelta di design documentata da un'assunzione mai verificata. Vale anche per chi progetta dati replicati per disaster recovery: gli obiettivi di tempo e punto di ripristino dicono quanta inconsistenza temporanea l'organizzazione accetta pur di restare in piedi, e quella cifra dovrebbe essere una decisione di chi risponde del rischio, non un effetto scoperto durante il primo incidente.