Escalabilidade e alta disponibilidade não são mais "diferenciais" — são requisitos básicos. Mas, quando entramos no mundo dos sistemas distribuídos, percebemos que não existe almoço grátis. Para garantir que sua aplicação continue rodando em múltiplos servidores, você precisa entender o Teorema CAP.
Neste post, vamos desmistificar esse dilema e ver como ele impacta suas escolhas de arquitetura.
O que é o Teorema CAP?
Proposto por Eric Brewer, o Teorema CAP afirma que um sistema distribuído de dados pode oferecer, simultaneamente, apenas duas de três garantias:
C (Consistency - Consistência): Toda leitura recebe a gravação mais recente ou um erro. O sistema se comporta como se houvesse apenas uma cópia dos dados.
A (Availability - Disponibilidade): Toda requisição recebe uma resposta de sucesso (mesmo que não seja o dado mais recente), garantindo que o sistema nunca fique fora do ar.
P (Partition Tolerance - Tolerância a Partição): O sistema continua funcionando mesmo que a rede falhe e "quebre" a comunicação entre os nós.
O Dilema: Por que precisamos escolher?
Em sistemas distribuídos, a Partição de Rede (P) é inevitável. Cabos falham, roteadores engasgam e switches dão problema. Como não podemos evitar que a rede falhe, a decisão real do arquiteto é sempre entre Consistência (C) e Disponibilidade (A).
- Sistemas CP (Consistência + Partição) Se a rede falha, o sistema prefere "congelar" ou retornar um erro a entregar dados desatualizados.
Onde aplicar: Bancos de dados transacionais, sistemas financeiros e operações de checkout. A precisão dos dados vale mais do que a disponibilidade momentânea.
- Sistemas AP (Disponibilidade + Partição) O sistema prioriza continuar atendendo requisições, mesmo que isso signifique que o usuário veja um dado "um pouco atrasado".
Onde aplicar: Redes sociais, feeds de notícias, sistemas de busca. É melhor o usuário ver um comentário de 5 segundos atrás do que encontrar uma página de erro 500.
Aplicação no Mundo Real
Se você estiver construindo, por exemplo, um sistema de apostas (como estou fazendo em um dos meus projetos de estudo), a escolha depende do módulo:
Módulo de Pagamentos: Deve ser CP. Você não pode permitir que um saldo seja debitado duas vezes ou que fique negativo por falta de sincronia.
Módulo de Feed de Apostas: Pode ser AP. O usuário prefere ver a odd (cotação) com um delay de milissegundos do que ver o site fora do ar durante uma partida importante.
Conclusão
Não existe "bala de prata" na arquitetura. O Teorema CAP é uma ferramenta de decisão: antes de escolher seu banco de dados ou definir seu protocolo de replicação, pergunte-se: "O que dói mais no meu usuário final hoje: um dado desatualizado ou uma página de erro?".
A resposta para essa pergunta é o que definirá a arquitetura do seu próximo sistema.
Referências
BREWER, Eric A. Towards Robust Distributed Systems. PODC, 2000.
KLEPPMANN, Martin. Designing Data-Intensive Applications. O'Reilly Media, 2017.
Top comments (0)