Atualizado: 30 de junho de 2025 às 08:53

Leitura: 6 minutos de leitura

Criado: 28 de junho de 2025

O Teorema CAP Explicado

Por que um Sistema Distribuído não pode ser o Superman (mas pode ser o Batman ou o Flash)

Introdução

Continuando nossa "saga" (vamos falar sobre o padrão SAGA posteriormente) sobre System Design, hoje vamos falar sobre um grande dilema, uma lei universal em sistemas distribuído que nos obriga a fazer uma escolha impossível.

Dica

E se você ainda não viu os posts anteriores, confere lá, creio que vão te ajudar muito.

A escolha impossível

Diferente de alguns heróis da DC, que podem estar em todos os lugares ao mesmo tempo e saber de tudo, um sistema não pode ter esses superpoderes. Eles não podem ser, ao mesmo tempo, 100% Consistentes, 100% Disponíveis e 100% Tolerantes a falhas.
Esse é o dilema do Teorema CAP.

Entender essa escolha é uma decisão de arquitetura que define como sua aplicação se comportará sob estresse. Você precisa de um sistema que nunca falha em responder, mesmo que a informação esteja um pouco desatualizada, ou um que prefere ficar fora do ar a entregar um dado incorreto?
Vamos desconstruir essa escolha.

Os Três Poderes: C, A e P

Imagem do teorema CAP

C - Consistência (Consistency): O Poder da Onisciência (Dr. Manhattan)

Todos os servidores em um sistema distribuído enxergam exatamente a mesma versão dos dados ao mesmo tempo. Uma leitura sempre retornará o dado da escrita mais recente.

Para ilustrar, pense na Consistência como o Dr. Manhattan. Ele percebe o passado, o presente e o futuro como uma coisa só. Não há defasagem ou 'versões' da realidade para ele.

Em um sistema consistente (CP), como um sistema bancário, imagine que você faz uma transferência de R$ 500. No momento em que a transação é confirmada, o sistema precisa garantir que essa informação seja absoluta e universal. Se você consultar seu saldo em seu celular, e o gerente do banco consultar no computador da agência, ambos DEVEM ver o saldo com R$ 500 a menos, instantaneamente.

A - Disponibilidade (Availability): O Poder da Onipresença (Flash)

Toda requisição feita ao sistema recebe uma resposta (que não seja um erro). O sistema está sempre online e funcional, mesmo que isso signifique retornar um dado que não seja o mais recente (stale data).

A Disponibilidade é como o Flash (eu sei, o Flash não é exatamente onipresente e o Dr. Manhattan é de fato onipresente, mas vamos simplificar, ok? kkk). Não importa onde o problema aconteça, ele sempre vai aparecer pra ajudar. Ele está sempre... disponível

Um sistema disponível (AP) garante que, mesmo que a rede esteja instável, o usuário receberá uma resposta. Imagine o feed de uma rede social: é melhor carregar os posts de alguns minutos atrás do que mostrar uma tela de erro.

P - Tolerância a Partições (Partition Tolerance): O Poder da Resiliência (Batman)

O sistema continua operando mesmo que haja uma falha de comunicação (uma "partição") entre os servidores. Mensagens podem ser perdidas ou atrasadas, mas o sistema como um todo não para.

A Tolerância a Partições é a resiliência do Batman. Ele não tem superpoderes, e seus planos podem falhar (a comunicação com Alfred pode cair, um bat-rang pode errar o alvo). Mesmo assim, ele se adapta e continua a missão.

Em sistemas distribuídos na internet, falhas de rede SÃO uma certeza. A tolerância a partições não é uma escolha, é uma condição para sobreviver no mundo real.

O Conflito: Por que "P" Força uma Escolha entre "C" e "A"

Imagine que nosso sistema é uma rede de inteligência com dois espiões, um em cada continente. Eles precisam ter a mesma informação sobre uma missão. De repente, o cabo de comunicação submarino entre eles é rompido (uma partição de rede - P).

A Escolha (CP vs. AP):

CP (Consistência + Tolerância): O Sistema 'Precaução'

Se escolhermos a consistência (CP), o sistema prefere a integridade dos dados. O espião que recebe uma nova ordem (ex: 'abortar missão') não pode agir até que o outro espião confirme o recebimento. Para garantir que ninguém aja com dados diferentes, um deles (ou ambos) fica 'indisponível' até a comunicação voltar. A prioridade é evitar um erro catastrófico.

Exemplos: Bancos de dados relacionais, sistemas de controle de estoque, sistemas bancários.

AP (Disponibilidade + Tolerância): O Sistema 'Ação'

Se escolhermos a disponibilidade (AP), o sistema prefere continuar funcionando. Nossos espiões continuam agindo com base na última informação que tinham. Um pode achar que a missão ainda está de pé enquanto o outro já sabe que foi abortada. O sistema está 'disponível' para ambos, mas eles estão temporariamente inconsistentes. A prioridade é manter a operação.

Exemplos: Redes sociais, sistemas de analytics que podem tolerar uma pequena defasagem nos dados.

Nota

Para se aprofundar mais...

O Teorema CAP foi conceituado e apresentado publicamente pelo cientista da computação Eric Brewer em 2000, durante uma palestra no Simpósio sobre Princípios de Computação Distribuída (PODC).

O contexto da época foi crucial para o surgimento dessa ideia:

Ascensão da Internet: No final dos anos 1990 e início dos anos 2000, a internet estava explodindo em popularidade. Empresas como Google, Yahoo e eBay enfrentavam um desafio sem precedentes: escalar seus serviços para milhões de usuários.

Limitações da Escalabilidade Vertical: A abordagem tradicional de usar um único e poderoso servidor (escalabilidade vertical) estava se tornando inviável e cara demais para lidar com o crescimento exponencial do tráfego e dos dados.

Surgimento da Escalabilidade Horizontal: A solução foi começar a construir sistemas distribuídos, utilizando clusters de muitas máquinas mais baratas (commodity hardware) interligadas em rede.

Novos Desafios: Essa nova arquitetura trouxe um problema fundamental: como garantir que os dados sejam consistentes e que o sistema esteja sempre disponível, quando as falhas de comunicação entre essas máquinas são inevitáveis?

Foi nesse cenário que Eric Brewer formulou o Teorema CAP (inicialmente como uma conjectura), que forneceu um modelo mental claro para entender as trocas inevitáveis que os engenheiros precisavam fazer ao projetar esses novos sistemas distribuídos em larga escala. A ideia foi formalmente provada como um teorema dois anos depois, em 2002, pelos pesquisadores Seth Gilbert e Nancy Lynch do MIT.

Testando seu entendimento

Conclusão

O interesse é que, o Teorema CAP não diz qual sistema é melhor. Ele nos dá um mapa das decisões inevitáveis (trade-offs) que precisamos fazer ao implementar um sistema.

A regra é simples: na presença de falhas de rede (o que é quase sempre), você deve escolher entre garantir o dado perfeito (Consistência) ou a resposta perfeita (Disponibilidade).

Muito obrigado por ler até aqui, grande abraço e até a próxima!