Teorema CAP

O Teorema CAP, proposto por Eric Brewer em 2000 e formalmente provado por Seth Gilbert e Nancy Lynch em 2002¹, afirma que um sistema distribuído que replica dados entre nós não consegue garantir simultaneamente as três propriedades a seguir:

As três propriedades

Consistência (C) : Toda leitura retorna a escrita mais recente, ou um erro. Todos os nós veem os mesmos dados ao mesmo tempo — o equivalente à linearizabilidade em programação concorrente. Em um sistema consistente, é impossível ler dados desatualizados.

Disponibilidade (A) : Toda requisição recebe uma resposta que não é de erro. O sistema permanece operacional enquanto pelo menos um nó estiver em execução, ainda que a resposta possa não conter a escrita mais recente.

Tolerância a Partições (P) : O sistema continua operando apesar de partições arbitrárias da rede — mensagens perdidas ou atrasadas entre os nós. Partições são um fato inevitável em qualquer rede distribuída real; falhas de hardware, congestionamento e distâncias físicas podem causá-las.

Classes de sistemas

CP — Consistente e tolerante a partições

Durante uma partição, o sistema recusa requisições em vez de retornar dados possivelmente desatualizados. Quando a partição se resolve, a consistência é restaurada antes de voltar a atender.

Exemplos: PostgreSQL em modo distribuído, MongoDB (configuração padrão), Apache ZooKeeper, etcd.

Use quando: a correção é inegociável — transações financeiras, sistemas de estoque, repositórios de identidade.

Node A ──── [partition] ──── Node B
   │                            │
Client                       Returns error
writes here                  (unavailable)

AP — Disponível e tolerante a partições

Durante uma partição, todos os nós continuam respondendo, mas podem divergir e retornar dados diferentes. Depois que a partição se resolve, o sistema converge para um estado consistente (consistência eventual).

Exemplos: Apache Cassandra, Amazon DynamoDB, CouchDB, DNS.

Use quando: a disponibilidade importa mais do que a precisão momentânea — carrinhos de compras, feeds de redes sociais, índices de busca.

Node A ──── [partition] ──── Node B
   │                            │
Client A sees              Client B sees
version 5                  version 4 (stale)
         ← converge after partition heals →

CA — Consistente e disponível

Pressupõe que não há partições, o que só é realista para sistemas de uma única máquina ou LANs rigidamente controladas. Não é uma categoria prática para sistemas distribuídos.

Tabela comparativa

A extensão PACELC

O teorema CAP trata apenas do cenário de partição. O PACELC (Daniel Abadi, 2010)² o estende perguntando: mesmo quando não há partição, qual é o trade-off?

If Partition:
  → choose between Availability and Consistency
Else (normal operation):
  → choose between Latency and Consistency

O PACELC é mais útil do que o CAP para as escolhas de banco de dados do dia a dia, porque na maior parte do tempo não há partição — mas o trade-off entre latência e consistência está sempre presente.

Implicações práticas para o projeto de sistemas

Catálogo de produtos de e-commerce → AP : Mostrar um produto como disponível em estoque logo depois de ele ter esgotado é aceitável. Um breve período de dados desatualizados não compromete a correção.

Carrinho de compras → AP : Adicionar um item a um carrinho que diverge temporariamente entre as réplicas não é problema; o carrinho pode ser reconciliado no checkout.

Processamento de pagamentos → CP : Uma cobrança em dobro ou um débito perdido não pode ser reconciliado depois do fato. A consistência é obrigatória.

Autenticação de usuários → CP : Um token revogado precisa ficar imediatamente inválido em todos os nós. Estado de autenticação desatualizado é uma vulnerabilidade de segurança.