Você já se perguntou por que é tão difícil construir um sistema distribuído que seja rápido, confiável e sempre disponível? Na engenharia de sistemas distribuídos, isso não é apenas uma impressão é uma regra matemática chamada Teorema CAP.
O que é o Teorema CAP?
Proposto por Eric Brewer no início dos anos 2000, o Teorema CAP e diz o seguinte:
Em um sistema distribuído, não é possível garantir ao mesmo tempo Consistência, Disponibilidade e Tolerância a Partições.
Essas três características são chamadas de C, A e P. Vamos entender cada uma com calma.
Os Três Pilares (C-A-P)
- Consistência (C): todos os nós do sistema veem os mesmos dados ao mesmo tempo.
Exemplo: se você atualiza um registro em um servidor, todos os outros refletem essa mudança imediatamente. - Disponibilidade (A): o sistema sempre responde a uma requisição — mesmo que a resposta venha de um nó desatualizado.
Exemplo: você nunca recebe erro, mesmo que a informação ainda não esteja sincronizada. - Tolerância a Partições (P): o sistema continua funcionando mesmo quando há falhas de comunicação entre servidores (as famosas “partições de rede”).
A má notícia?
Durante uma falha de rede — e falhas sempre acontecem — é preciso escolher entre Consistência e Disponibilidade.
Por isso, o CAP costuma ser representado como um triângulo em que só é possível escolher dois lados.
Entendendo com exemplos práticos
Sistema CP (Consistência + Tolerância a Partições)
Imagine um banco: é melhor negar uma transação do que permitir dados incorretos.
Se a rede falha, ele prioriza consistência, mesmo que isso torne o sistema temporariamente indisponível.
Exemplos: bancos de dados como HBase ou MongoDB em modo de consistência forte.
Sistema AP (Disponibilidade + Tolerância a Partições)
Agora pense em uma rede social: quando você curte uma foto, o sistema mostra sua curtida na hora, mesmo que outro servidor ainda não tenha recebido essa atualização.
A prioridade aqui é manter a resposta ao usuário, mesmo que os dados levem um tempo para se alinhar.
Exemplos: Cassandra, DynamoDB, CouchDB.
Sistema CA (Consistência + Disponibilidade)
Seria o mundo ideal, mas… ele só existe se não houver falhas de rede.
Em sistemas realmente distribuídos, esse cenário é praticamente impossível.
O que isso muda na prática?
O Teorema CAP vai além da teoria: ele orienta decisões de arquitetura.
Cada escolha depende do contexto e da prioridade do negócio.
- E-commerce: prioriza consistência (ninguém quer vender um produto esgotado).
- Redes sociais: priorizam disponibilidade (ninguém quer ver erro ao curtir um post).
- Saúde ou bancos: consistência quase sempre vem em primeiro lugar.
Conclusão
O Teorema CAP nos lembra que não existe almoço grátis em sistemas distribuídos.
Cada decisão de arquitetura envolve trocas — e compreender o CAP é o primeiro passo para fazer escolhas conscientes e alinhadas ao propósito do sistema.