Il Teorema CAP: Consistenza, Disponibilità e Tolleranza alle Partizioni

Il Teorema CAP, formulato da Eric Brewer, è un principio fondamentale nella progettazione di sistemi di dati distribuiti. Afferma che un sistema distribuito può fornire al massimo due delle seguenti tre garanzie contemporaneamente:

• Consistency (Consistenza): Ogni lettura riceve la scrittura più recente o un errore. Tutti i nodi del sistema vedono gli stessi dati nello stesso momento.
• Availability (Disponibilità): Ogni richiesta riceve una risposta (non un errore), senza garanzia che contenga la scrittura più recente. Il sistema è sempre operativo.
• Partition Tolerance (Tolleranza alle Partizioni): Il sistema continua a operare anche se si verifica una "partizione di rete", ovvero se la comunicazione tra due nodi del sistema si interrompe.

La Scelta Obbligata: AP o CP?

In un sistema distribuito (come quasi tutti i database NoSQL), la tolleranza alle partizioni (P) non è un'opzione, ma una necessità. Le reti non sono affidabili e le interruzioni di comunicazione possono sempre accadere. Pertanto, la vera scelta che i progettisti di database devono fare è tra consistenza e disponibilità.

Sistemi AP (Availability + Partition Tolerance)

Quando si verifica una partizione, il sistema sceglie di rimanere disponibile. Questo significa che continuerà a rispondere alle richieste, anche se questo comporta il rischio che alcuni nodi restituiscano dati non aggiornati ("stale"). Si sacrifica la consistenza per la disponibilità. Questo approccio è spesso chiamato "consistenza eventuale" (eventual consistency).

• Esempi: Cassandra, CouchDB, DynamoDB (nella sua configurazione di default).
• Ideale per: Applicazioni dove l'alta disponibilità è più importante della consistenza forte istantanea (es. social media, dove vedere un "like" con qualche secondo di ritardo non è un problema).

Sistemi CP (Consistency + Partition Tolerance)

Quando si verifica una partizione, il sistema sceglie di preservare la consistenza. Se un nodo non può garantire di avere l'ultima versione di un dato, restituirà un errore o si rifiuterà di rispondere, sacrificando la disponibilità.

• Esempi: MongoDB, Redis, HBase.
• Ideale per: Applicazioni che richiedono una forte consistenza dei dati (es. sistemi di pagamento, gestione dell'inventario).

I database relazionali tradizionali, in un setup a singolo server, sono CA (Consistenti e Disponibili), ma non sono tolleranti alle partizioni per natura.