Vamos fazer uma análise mais profunda sobre as três características do sistema distribuído ao qual o teorema CAP se refere.

Consistência

Consistência significa que todos os clientes veem os mesmos dados ao mesmo tempo, não importa em qual nó eles se conectem. Para que isso aconteça, sempre que os dados forem gravados em um nó, ele deve ser instantaneamente encaminhado ou replicado para todos os outros nós do sistema antes que a gravação seja considerada 'bem-sucedida'.

Disponibilidade

Disponibilidade significa que qualquer cliente que fizer uma solicitação de dados obterá uma resposta, mesmo que um ou mais nós estejam desativados. Ou seja, todos os nós em funcionamento no sistema distribuído retornam uma resposta válida para qualquer solicitação, sem exceção.

Tolerância de partição

Uma partição é uma quebra de comunicações dentro de um sistema distribuído, uma conexão perdida ou temporariamente lenta entre dois nós. Tolerância de partição significa que o cluster deve continuar a funcionar mesmo se ocorrer uma ou mais falhas de comunicação entre os nós no sistema.

Bancos de dados NoSQL são ideais para aplicações de rede distribuída. Diferentemente de suas contrapartes SQL (relacionais) verticalmente escaláveis, os bancos de dados NoSQL são horizontalmente escaláveis e foram criados para serem distribuídos. É possível ajustar sua escala rapidamente em uma rede crescente consistindo em múltiplos nós interconectados. (Consulte "Bancos de dados SQL vs. NoSQL: qual é a diferença?" para obter mais informações.)

Atualmente, bancos de dados NoSQL são classificados com base nas duas características do CAP que eles suportam:

• Banco de dados CP: um banco de dados CP entrega consistência e tolerância de partição em detrimento da disponibilidade. Quando uma partição ocorre entre dois nós quaisquer, o sistema deverá desativar 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 entrega 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 outros. (Quando a partição é resolvida, os bancos de dados AP tipicamente ressincronizam os nós para reparar todas as inconsistências no sistema.)
  
  
• Banco de dados CA: um banco de dados CA entrega consistência e disponibilidade em todos os nós. Porém, isso não é possível se houver uma partição entre dois nós quaisquer no sistema, no entanto, e, portanto, não poderá entregar tolerância a falhas.

Listamos o tipo de banco de dados CA por último pelo seguinte motivo: em um sistema distribuído, partições não podem ser evitadas. Por isso, enquanto podemos discutir um banco de dados distribuído CA em teoria, para todos os efeitos práticos, um banco de dados distribuído CA não pode existir. Isso não significa que você não pode ter um banco de dados CA para o seu aplicativo distribuído se você precisar de um. Muitos bancos de dados relacionais, como o PostgreSQL entregam consistência e disponibilidade e podem ser implementados em múltiplos nós usando replicação.

O MongoDB é um sistema de gerenciamento de banco de dados NoSQL bastante conhecido que armazena dados como documentos BSON (JSON binário). É usado frequentemente para big data e aplicativos em tempo real em execução em vários locais diferentes. Relativo ao teorema CAP, o MongoDB é um armazenamento de dados CP, ou seja, resolve partições de rede mantendo a consistência, porém, não oferece disponibilidade.

O MongoDB é um sistema de mestre único, cada conjunto de réplica (link externo à ibm.com) 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ção do nó primário e o aplicam ao seu próprio conjunto de dados. Por padrão, os clientes leem a partir do nó primário, mas também podem especificar uma preferência de leitura (link externo à ibm.com) que os permite ler a partir de nós secundários.

Quando o nó primário fica indisponível, o nó secundário com o log de operação mais recente será eleito como o novo nó primário. Uma vez que todos os outros nós secundários passam a acompanhar o novo mestre, o cluster torna-se disponível novamente. Como os clientes não podem fazer nenhuma solicitação de gravação durante este intervalo, os dados permanecem consistentes em toda a rede.

O Apache Cassandra é um banco de dados NoSQL de software livre mantido pela Apache Software Foundation. É um banco de dados de coluna ampla que permite armazenar dados em uma rede distribuída. No entanto, ao contrário do MongoDB, o Cassandra tem uma arquitetura sem mestre e, portanto, ela tem diversos pontos de falha, em vez de um único.

Em relação ao teorema CAP, o Cassandra é um banco de dados AP, ou seja, ele entrega disponibilidade e tolerância de partição, mas não consegue entregar consistência o tempo todo. Como o Cassandra não tem um nó principal, todos os nós devem estar disponíveis de maneira contínua. No entanto, o Cassandra fornece consistência eventual permitindo que os clientes escrevam para qualquer nós a qualquer momento e resolvam inconsistências o mais rápido possível.

Uma vez que os dados só se tornam inconsistentes no caso de uma partição de rede e as inconsistências são rapidamente resolvidas, o Cassandra oferece a funcionalidade "reparar" para ajudar os nós a recuperar o atraso com relação aos seus pares. No entanto, a disponibilidade constante resulta em um sistema de alto desempenho, o que pode compensar em muitos casos.

Os microsserviços são componentes de aplicativos implementáveis de forma independente e fracamente acoplados que possuem seus próprios recursos, incluindo seu próprio banco de dados e modelo de banco de dados, e se comunicam entre si por meio de uma rede. Como é possível executar microsserviços tanto em servidores de cloud quanto em data centers locais, eles se tornaram extremamente requisitados para aplicativos híbridos e multicloud.

Entender o teorema CAP pode ajudá-lo a escolher o melhor banco de dados ao desenvolver um aplicativo com base em microsserviços que são executados a partir de vários locais. Por exemplo, se a capacidade de rapidamente iterar o modelo de dados e escalar horizontalmente for essencial para o seu aplicativo e caso ele possa tolerar uma consistência eventual (em vez de restrita), um banco de dados AP como o Cassandra ou Apache CouchDB pode atender seus requisitos e simplificar sua implementação. Por outro lado, caso seu aplicativo seja altamente dependente da consistência de dados, como em um aplicativo de eCommerce ou um serviço de pagamento, recomenda-se optar por um banco de dados relacional como o PostgreSQL.