Existe uma regra fundamental em sistemas distribuídos que nenhuma engenharia consegue contornar — não importa o quão sofisticado seja o banco de dados, o cloud provider ou a arquitetura escolhida.
Você nunca vai ter tudo ao mesmo tempo.
Essa é a essência do Teorema CAP, proposto por Eric Brewer em 2000 e formalmente provado por Seth Gilbert e Nancy Lynch em 2002. Ele descreve um limite físico e matemático do design de sistemas distribuídos: das três propriedades fundamentais que um sistema pode ter, você só consegue garantir duas delas simultaneamente.
As três propriedades do Teorema CAP
C — Consistência (Consistency)
Todos os nós do sistema enxergam os mesmos dados ao mesmo tempo. Após uma operação de escrita, qualquer leitura subsequente — em qualquer nó — retorna o valor mais recente.
Em termos práticos: se você escreveu “X = 10” em um nó, qualquer outro nó que ler X imediatamente depois vai ver 10 — nunca um valor desatualizado.
A — Disponibilidade (Availability)
O sistema responde a todas as requisições, sempre — mesmo que alguns nós estejam com falha. Nenhuma requisição fica sem resposta.
Em termos práticos: o sistema nunca retorna um erro por indisponibilidade. Pode retornar um dado levemente desatualizado, mas sempre retorna alguma coisa.
P — Tolerância à Partição (Partition Tolerance)
O sistema continua operando mesmo quando há falha de comunicação entre nós — ou seja, quando a rede “parte” e alguns nós ficam sem conseguir se comunicar com outros.
Em termos práticos: uma queda de link entre data centers não derruba o sistema. Ele segue funcionando nos dois lados da partição.
Por que você só pode escolher dois
O teorema diz que um sistema distribuído pode garantir no máximo duas dessas três propriedades ao mesmo tempo — nunca as três simultaneamente.
CP — Consistência + Tolerância à Partição
O sistema garante que todos os nós têm os mesmos dados e sobrevive a partições de rede — mas pode se tornar indisponível durante uma falha enquanto aguarda sincronização.
Exemplos: HBase, Zookeeper, MongoDB (em configurações estritas)
AP — Disponibilidade + Tolerância à Partição
O sistema sempre responde e sobrevive a partições — mas durante uma falha de rede, nós diferentes podem retornar dados diferentes até que a sincronização se complete.
Exemplos: Cassandra, CouchDB, DynamoDB
CA — Consistência + Disponibilidade
O sistema garante consistência e está sempre disponível — mas não tolera partições de rede. Na prática, isso significa que o sistema só funciona em ambiente de rede confiável, sem distribuição real.
Exemplos: bancos de dados relacionais tradicionais (PostgreSQL, MySQL) em configuração single-node
Atenção: em um sistema verdadeiramente distribuído, partições de rede são inevitáveis. Por isso, na prática, a escolha real sempre se resume a CP ou AP — a tolerância à partição raramente é opcional.
O que isso significa na prática
Antes de escolher um banco de dados ou desenhar uma arquitetura distribuída, a pergunta que você precisa responder é:
Quando algo der errado na rede — e vai dar — o que é mais crítico para o seu sistema: que todos os nós tenham o mesmo dado, ou que o sistema continue respondendo?
Se a resposta for “dado consistente, mesmo que o sistema trave por um momento” → CP
Se a resposta for “sistema sempre disponível, mesmo que um nó retorne dado levemente defasado” → AP
Não existe resposta certa. Existe a resposta certa para o seu caso de uso.
Referências
- Brewer, E. (2000). Towards Robust Distributed Systems. PODC Keynote.
- Gilbert, S. & Lynch, N. (2002). Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. ACM SIGACT News.