Esaminiamo in modo dettagliato le tre caratteristiche del sistema distribuito a cui si riferisce il teorema CAP.

Consistenza

Consistenza significa che tutti i clienti vedono contemporaneamente gli stessi dati, indipendentemente dal nodo a cui si connettono. Affinché ciò accada, ogni volta che i dati vengono scritti su un nodo, devono essere immediatamente inoltrati o replicati a tutti gli altri nodi nel sistema prima che la scrittura venga considerata "riuscita".

Disponibilità

Disponibilità significa che un cliente che effettua una richiesta di dati riceve una risposta, anche se uno o più nodi sono inattivi. In altre parole, tutti i nodi funzionanti nel sistema distribuito restituiscono una risposta valida per qualsiasi richiesta, senza eccezioni.

Tolleranza alle partizioni

Una partizione è un'interruzione delle comunicazioni all'interno di un sistema distribuito: una connessione persa o temporaneamente ritardata tra due nodi. La tolleranza alle partizioni significa che il cluster deve continuare a funzionare anche quando si verificano interruzioni di comunicazione tra i nodi del sistema.

I database NoSQL sono ideali per le applicazioni di rete distribuite. A differenza delle loro controparti SQL (relazionali) scalabili verticalmente, i database NoSQL sono scalabili orizzontalmente e distribuiti by design: possono adattarsi rapidamente a una rete in crescita composta da più nodi interconnessi. (Per maggiori informazioni, vedi "Database SQL e NoSQL: qual è la differenza?")

Oggi, i database NoSQL sono classificati in base alle due caratteristiche CAP supportate:

• Database CP: un database CP offre consistenza e tolleranza alle partizioni a scapito della disponibilità. Quando si verifica una partizione tra due nodi, il sistema deve arrestare il nodo non coerente (ovvero renderlo non disponibile) fino a quando la partizione non viene risolta.
  
  
• Database AP: un database AP offre disponibilità e tolleranza alle partizioni a scapito della consistenza. Quando si verifica una partizione, tutti i nodi rimangono disponibili, ma quelli dal lato sbagliato di una partizione potrebbero restituire una versione precedente dei dati rispetto ad altri. (Quando la partizione viene risolta, i database AP solitamente risincronizzano i nodi per riparare tutte le inconsistenze nel sistema).
  
  
• Database CA: un database CA offre consistenza e disponibilità su tutti i nodi. Tuttavia, non può farlo se esiste una partizione tra due nodi nel sistema e quindi non può garantire tolleranza agli errori.

Abbiamo elencato per ultimo il tipo di database CA per una ragione ben precisa: in un sistema distribuito, le partizioni non si possono evitare. Pertanto, mentre in teoria possiamo parlare di un database distribuito CA, nella pratica un database distribuito CA non può esistere. Ciò non significa che non sia possibile, laddove necessario, avere un database CA per la propria applicazione distribuita. Molti database relazionali, come PostgreSQL, offrono consistenza e disponibilità e possono essere distribuiti su più nodi tramite replica.

MongoDB è un sistema di gestione database NoSQL molto diffuso che archivia i dati come documenti BSON (JSON binario). Viene spesso utilizzato per big data e applicazioni in tempo reale in esecuzione in più sedi diverse. Rispetto al teorema CAP, MongoDB è un archivio dati CP: risolve le partizioni di rete mantenendo la consistenza, ma scendendo a compromessi a livello di disponibilità.

MongoDB è un sistema single-master: ogni set di repliche può avere un solo nodo primario che riceve tutte le operazioni di scrittura. Tutti gli altri nodi nella stessa serie di replica sono nodi secondari che replicano il log delle operazioni del nodo primario e lo applicano alla propria serie di dati. Di default anche i client leggono dal nodo primario, ma possono anche specificare una preferenza di lettura che consente loro di leggere da nodi secondari.

Quando il nodo primario diventa non disponibile, il nodo secondario con il log operazioni più recente sarà scelto come nuovo nodo primario. Dopo che tutti gli altri nodi secondari raggiungono il nuovo master, il cluster diventa nuovamente disponibile. Poiché i client non possono effettuare richieste di scrittura durante questo intervallo, i dati rimangono consistenti su tutta la rete.

Apache Cassandra è un database NoSQL open source gestito dalla Apache Software Foundation. È un database a colonne larghe che consente di archiviare dati su una rete distribuita. Tuttavia, a differenza di MongoDB, Cassandra ha un'architettura senza master e, di conseguenza, ha più punti di errore, invece di uno solo.

Rispetto al teorema CAP, Cassandra è un database AP: offre disponibilità e tolleranza alle partizioni, ma non è in grado di garantire sempre consistenza. Poiché Cassandra non ha un nodo master, tutti i nodi devono essere disponibili continuamente. Tuttavia, Cassandra fornisce consistenza finale consentendo ai client di scrivere su qualsiasi nodo in qualsiasi momento e riconciliando le incongruenze il più rapidamente possibile.

Poiché i dati diventano inconsistenti solo nel caso di una partizione di rete e le inconsistenze si risolvono rapidamente, Cassandra offre una funzionalità di "riparazione" per aiutare i nodi a mettersi in pari con i loro corrispondenti. Tuttavia, la disponibilità costante determina un sistema ad alte prestazioni, che in molti casi potrebbe valere il compromesso.

I microservizi sono componenti applicativi liberamente accoppiati e distribuibili in modo indipendente che incorporano il proprio stack, inclusi il proprio database e il proprio modello di database, e comunicano tra loro tramite una rete. Poiché è possibile eseguire i microservizi sia su server cloud che su data center on-premises, sono diventati molto popolari per le applicazioni ibride e multicloud.

La comprensione del teorema CAP può aiutare a scegliere il database migliore nella progettazione di un'applicazione basata su microservizi in esecuzione da più sedi. Ad esempio, se la capacità di iterare rapidamente il modello di dati e ridimensionare orizzontalmente è essenziale per l'applicazione, tuttavia è possibile tollerare un'eventuale (e non rigida) consistenza, un database AP come Cassandra o Apache CouchDB può soddisfare i requisiti e semplificare l'implementazione. Se invece l'applicazione dipende strettamente dall'uniformità dei dati, come in un'applicazione di e-commerce o in un servizio di pagamento, di potrebbe scegliere un database relazionale come PostgreSQL.