Vamos dar uma olhada detalhada nas três características do sistema distribuído às quais o teorema CAP se refere.

Consistência

Consistência significa que todos os clientes veem os mesmos dados ao mesmo tempo, independentemente do nó ao qual se conectam. Para que isso aconteça, sempre que os dados forem gravados em um nó, eles deverão ser imediatamente encaminhados ou replicados para todos os outros nós no sistema antes que a gravação seja considerada "sucesso".

Disponibilidade

Disponibilidade significa que qualquer cliente que faça uma solicitação de dados recebe uma resposta, mesmo que um ou mais nós estejam inativos. Outra forma de afirmar isso: todos os nós em funcionamento no sistema distribuído retornam uma resposta válida para qualquer solicitação, sem exceção.

Tolerância à partição

Uma partição é uma quebra de comunicação dentro de um sistema distribuído — uma conexão perdida ou temporariamente atrasada entre dois nós. Tolerância de partição significa que o cluster deve continuar funcionando apesar de qualquer número de quebras de comunicação entre nós no sistema.

Bancos de dados NoSQL são ideais para aplicações em redes distribuídas. Diferente de seus equivalentes SQL (relacionais) escaláveis verticalmente, os bancos de dados NoSQL são escaláveis horizontalmente e distribuídos por design. Eles podem escalar rapidamente em uma rede crescente composta por vários nós interconectados (veja "SQL vs. bancos de dados NoSQL: qual a diferença?" para mais informações).

Atualmente, os bancos de dados NoSQL são classificados com base nas duas características CAP compatíveis:

• Banco de dados CP: Um banco de dados CP oferece consistência e tolerância à partição em detrimento da disponibilidade. Quando uma partição ocorre entre quaisquer dois nós, o sistema tem que desligar o nó não consistente (ou seja, torná-lo indisponível) até que a partição seja resolvida.
  
  
• Banco de dados AP: um banco de dados AP oferece disponibilidade e tolerância de partição em detrimento da consistência. Quando ocorre uma partição, todos os nós permanecem disponíveis, mas aqueles na extremidade errada de uma partição podem retornar uma versão mais antiga dos dados do que os outros. (Quando a partição é resolvida, os bancos de dados AP normalmente sincronizam novamente os nós para corrigir todas as inconsistências no sistema.)
  
  
• Banco de dados CA: um banco de dados CA oferece consistência e disponibilidade em todos os nós. Não é possível fazer isso se houver uma partição entre quaisquer dois nós no sistema, no entanto, e, portanto, não pode fornecer tolerância a falhas.

Mencionamos o tipo de banco de dados CA por último por um motivo: em um sistema distribuído, partições não podem ser evitadas. Assim, embora possamos discutir teoricamente um banco de dados CA distribuído, para todos os propósitos práticos, ele não pode existir. Isso não significa que você não possa ter um banco de dados CA para sua aplicação distribuída, se for necessário. Muitos bancos de dados relacionais, como o PostgreSQL, oferecem consistência e disponibilidade e podem ser implementados em vários nós usando replicação.

O MongoDB é um sistema de gerenciamento de banco de dados NoSQL popular que armazena dados como documentos BSON (JSON binário). É frequentemente utilizado para big data e aplicações em tempo real que rodam em diferentes locais. Em relação ao teorema CAP, o MongoDB é um armazenamento de dados CP. Ele resolve partições de rede mantendo a consistência, enquanto compromete a disponibilidade.

O MongoDB é um sistema single-master, ou seja, cada conjunto de réplicas pode ter apenas um nó primário que recebe todas as operações de gravação. Todos os outros nós no mesmo conjunto de réplicas são nós secundários que replicam o log de operações do nó primário e o aplicam ao seu próprio conjunto de dados. Por padrão, os clientes também leem do nó primário, mas podem especificar uma preferência de leitura que permite ler dos nós secundários.

Quando o nó primário ficar indisponível, o nó secundário com o registo de operação mais recente será eleito como o novo nó primário. Quando todos os outros nós secundários alcançam o novo mestre, o cluster fica disponível novamente. Como os clientes não podem fazer solicitações de gravação durante esse intervalo, os dados permanecem consistentes em toda a rede.

O Apache Cassandra é um banco de dados NoSQL de código aberto mantido pela Apache Software Foundation. É um banco de dados de colunas amplas que permite armazenar dados em uma rede distribuída. No entanto, ao contrário do MongoDB, Cassandra tem uma arquitetura sem mestre e, como resultado, tem vários pontos de falha, em vez de um único.

Em relação ao teorema CAP, o Cassandra é um banco de dados AP — ele oferece disponibilidade e tolerância à partição, mas não consegue fornecer consistência o tempo todo. Como o Cassandra não tem um nó mestre, todos os nós devem estar disponíveis continuamente. No entanto, o Cassandra fornece consistência eventual, permitindo que os clientes gravem em qualquer nó a qualquer momento e reconciliem as inconsistências o mais rápido possível.

Como os dados só se tornam inconsistentes no caso de uma partição de rede e as inconsistências são resolvidas rapidamente, o Cassandra oferece a funcionalidade de "reparo" para ajudar os nós a se aproximarem de seus pares. No entanto, a disponibilidade constante resulta em um sistema de alto desempenho que pode valer o trade-off em muitos casos.

Microsserviços são componentes de aplicação fracamente acoplados e implementáveis de forma independente, que incorporam seu próprio stack (incluindo seu próprio banco de dados e modelo de banco de dados) e se comunicam entre si por meio de uma rede. Como os microsserviços podem ser executados tanto em servidores de nuvem quanto em data centers locais, eles se tornaram altamente populares para aplicações híbridas e de multinuvem.

Entender o teorema CAP pode ajudar você a escolher o melhor banco de dados ao projetar uma aplicação baseada em microsserviços que opera em várias localizações. Por exemplo, se a capacidade de iterar rapidamente o modelo de dados e escalar horizontalmente é essencial para sua aplicação, mas você pode tolerar consistência eventual (em oposição à consistência estrita), um banco de dados AP como Cassandra ou Apache CouchDB pode atender às suas necessidades e simplificar sua implementação. Por outro lado, se sua aplicação depende fortemente da consistência dos dados, como em uma aplicação de eCommerce ou um serviço de pagamento, você pode optar por um banco de dados relacional como PostgreSQL.