O Teorema CAP afirma que um sistema distribuído pode garantir, no máximo, duas das três propriedades ao mesmo tempo: Consistência (C), Disponibilidade (A) e Tolerância a Partições (P).
Formulado por Eric Brewer em 2000 e provado formalmente por Gilbert e Lynch em 2002.
As três propriedades
Consistency (Consistência): qualquer leitura retorna o dado mais recente ou um erro. Todos os nós enxergam o mesmo dado ao mesmo tempo.
Availability (Disponibilidade): qualquer requisição recebe uma resposta (sem erro), mas sem garantia de que o dado é o mais recente.
Partition Tolerance (Tolerância a Partições): o sistema continua operando mesmo quando mensagens entre nós são perdidas ou atrasadas por falha de rede.
A escolha que importa na prática
Partições de rede são inevitáveis em sistemas distribuídos. A escolha real não é “dois de três” no sentido amplo, é sempre entre CP e AP, porque P não é opcional em produção.
CP: Consistência + Tolerância a Partições
Quando ocorre uma partição, o sistema prefere retornar erro ou timeout a entregar dados desatualizados.
Exemplos: HBase, Zookeeper, etcd, Redis Cluster, MongoDB (leitura do primário).
Casos de uso: saldo bancário, estoque de produtos, reservas, qualquer contexto em que dado obsoleto cause dano real.
Cliente → Nó A → [partição] → Nó B (não alcançável)
Resultado: o nó A retorna erro em vez de servir dados potencialmente desatualizados
AP: Disponibilidade + Tolerância a Partições
Quando ocorre uma partição, o sistema continua respondendo com o dado que tem, mesmo que desatualizado. Após a partição ser resolvida, os nós convergem (consistência eventual).
Exemplos: Cassandra, CouchDB, DynamoDB (modo padrão), Riak.
Casos de uso: feeds de redes sociais, DNS, contadores aproximados, carrinho de compras, buscas.
Cliente → Nó A → [partição] → Nó B (não alcançável)
Resultado: o nó A responde com a versão local; após resolução, A e B sincronizam
CA: Consistência + Disponibilidade
Existe apenas sem partições de rede, o que só é viável num sistema não distribuído (banco single-node). PostgreSQL ou MySQL rodando em um único servidor são CA na prática, mas não toleram partições por definição.
Consistência eventual vs forte
Consistência forte (strong consistency): após uma escrita confirmada, qualquer leitura subsequente retorna o valor escrito. Exige coordenação entre nós a cada operação, o que adiciona latência.
Consistência eventual (eventual consistency): o sistema garante que, sem novas escritas, todos os nós convergerão para o mesmo valor em algum momento. O intervalo de convergência é variável.
Cassandra permite ajuste fino via CONSISTENCY LEVEL:
| Nível | Nós que devem responder | Comportamento |
|---|---|---|
ONE | 1 | Mais rápido, menos consistente |
QUORUM | Maioria (N/2 + 1) | Equilíbrio |
ALL | Todos | Mais consistente, menos disponível |
QUORUM em leitura e escrita juntos garante que pelo menos um nó sempre tem o dado mais recente, mesmo sem consistência forte.
PACELC: extensão do CAP
O CAP descreve só o comportamento em falhas. Daniel Abadi propôs o PACELC para cobrir o caso sem falhas também:
Se há Partição (P): escolha entre Availability (A) e Consistency (C).
Senão (E): escolha entre Latency (L) e Consistency (C).
Mesmo sem falhas, consistência forte exige que nós se coordenem antes de responder, adicionando latência. É um trade-off permanente, não só em situações de falha.
| Banco | Partição | Sem partição |
|---|---|---|
| Cassandra | AP | EL (prioriza baixa latência) |
| DynamoDB | AP (padrão) | EL |
| Zookeeper | CP | EC (prioriza consistência) |
| MongoDB | CP | EC (leitura do primário) |
| CockroachDB | CP | EC |
Limitações do teorema
O CAP original trata “consistência” como linearizabilidade (a forma mais forte), mas sistemas reais operam com modelos mais fracos: causalidade, sessão, monotonia. Um banco pode ser “eventualmente consistente” com garantias bem específicas que não se encaixam exatamente em C ou A.
Na prática, a maioria dos bancos modernos oferece configuração do nível de consistência por operação, o que torna a classificação binária do CAP uma simplificação útil, não uma descrição completa do comportamento.
Conexões
- db-nosql: bancos AP e CP na prática (Cassandra, MongoDB, Redis)
- db-relacional: modelo CA de ponto de partida (single-node)
- db-tipos-de-bancos-de-dados: visão geral comparativa
- gcp-bigtable: sistema distribuído CP do Google
- gcp-spanner: externaliza consistência forte globalmente (contorna o CAP com TrueTime)
- gcp-firestore: AP com consistência eventual configurável
Referências
- Eric Brewer, Towards Robust Distributed Systems (2000, keynote PODC)
- Gilbert & Lynch, Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services (2002)
- Daniel Abadi, Problems with CAP, and Yahoo’s little known NoSQL system (2010)
- Martin Kleppmann, Designing Data-Intensive Applications, cap. 9