Pular para o conteúdo

Consistência, disponibilidade e partição

Avançado16 min de leiturafundamentos

O teorema CAP é citado com frequência e entendido com menos. A leitura popular — “escolha dois entre consistência, disponibilidade e tolerância a partição” — é imprecisa o suficiente para levar a decisões erradas.

A formulação correta é mais estreita e mais útil: quando ocorre uma partição de rede, um sistema distribuído precisa escolher entre consistência e disponibilidade. Fora da partição, não há dilema nenhum.

A confusão começa em tratar o P como escolha. Partição é um evento da rede: cabo rompido, switch reiniciando, zona isolada, latência tão alta que equivale a desconexão. Você não decide se ela acontece — decide o que o sistema faz quando acontece.

Por isso, todo sistema distribuído é “P”. A escolha real é entre CP e AP:

  • CP — diante da partição, o sistema recusa operações que não consegue garantir consistentes. Fica indisponível para preservar correção.
  • AP — o sistema aceita operações nos dois lados da partição e reconcilia depois. Fica disponível, com risco de divergência.

Sistema de um nó só não está sujeito ao teorema. Ele simplesmente cai inteiro.

Traduzindo para decisões concretas:

Situação Escolha adequada Por quê
Saldo, estoque, cobrança CP Vender o mesmo item duas vezes custa mais que ficar 5 minutos fora
Carrinho de compras AP Reconciliar itens é aceitável; perder o carrinho não
Contador de visualizações AP Precisão exata não tem valor
Autorização e permissões CP Permissão revogada precisa valer
Log de eventos AP Ordem parcial é suficiente
Cache AP Por definição, pode estar velho

A pergunta que revela a resposta: se ficarmos indisponíveis por cinco minutos, o prejuízo é maior ou menor que ter dois valores conflitantes para o mesmo registro?

Sistemas AP oferecem consistência eventual: sem novas escritas, todas as réplicas convergem para o mesmo valor em algum momento. “Algum momento” costuma ser milissegundos — e é exatamente por ser curto que o problema passa despercebido em teste e aparece em produção.

O efeito visível é conhecido: o usuário salva o perfil, a escrita vai para o primário, a leitura seguinte vai para uma réplica atrasada e a tela mostra o valor antigo.

Os padrões que resolvem, em ordem de simplicidade:

  • Leia do primário logo após escrever (read-your-writes), pelo tempo do atraso esperado.
  • Sessão consistente: a mesma sessão sempre lê da mesma réplica.
  • Monitorar o atraso e tirar do rodízio a réplica que passou do limite.
  • Modelar para convergir: estruturas que se fundem sem conflito (contadores por réplica, conjuntos com marcação de remoção) em vez de “o último a escrever vence”.

CAP só descreve o que acontece durante uma partição — que é raro. PACELC completa a frase:

Se houver Partição, escolha entre Availability e Consistency; Else (no dia a dia normal), escolha entre Latency e Consistency.

Essa segunda metade é a que afeta o seu sistema agora. Replicação síncrona garante que nada se perde no failover e faz cada escrita esperar a réplica confirmar. Assíncrona responde rápido e aceita perder as últimas transações se o primário morrer.

É a mesma decisão descrita em alta disponibilidade, com outro nome — e ela é tomada em toda arquitetura, todo dia, mesmo por quem nunca ouviu falar de CAP.

O erro prático não é escolher errado: é não escolher, e descobrir a escolha durante o incidente. Duas recomendações concretas:

  1. Decida por serviço, não pela empresa. A mesma organização deve ter o serviço de pagamentos em CP e o de recomendação em AP. Uniformidade aqui é preguiça travestida de padronização.
  2. Documente junto do serviço. Uma linha no repositório — “em partição, recusamos escrita” — vale mais que qualquer diagrama, porque é o que a pessoa de plantão precisa saber às 3h.

E desconfie de qualquer produto que prometa as três propriedades sem ressalva. Bancos distribuídos modernos entregam consistência forte com alta disponibilidade prática, mas pagam em latência e em custo — o trade-off não desaparece, ele muda de lugar.