System Design/01 - Fundamentos2 min
CAP Theorem
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Num sistema distribuído é impossível garantir simultaneamente as três propriedades:
| Letra | Propriedade | Significa |
|---|---|---|
| C | Consistency | Toda leitura vê a escrita mais recente (ou um erro) |
| A | Availability | Toda requisição recebe resposta não-erro |
| P | Partition tolerance | O sistema continua operando apesar de mensagens perdidas entre nós |
A leitura correta do teorema
A formulação popular "escolha 2 de 3" é enganosa. Partição de rede não é uma opção — é um fato da natureza em qualquer sistema distribuído. Cabos falham, switches reiniciam, datacenters se isolam.
Portanto P é obrigatório, e a escolha real é: quando houver uma partição, o que fazer?
- CP — recusar responder até ter certeza. Preserva consistência, sacrifica disponibilidade.
- AP — responder com o dado que se tem localmente. Preserva disponibilidade, aceita divergência.
Fora de partição — que é 99,9% do tempo — o sistema pode ser consistente e disponível. O teorema só se manifesta durante a falha.
PACELC — a extensão que completa o quadro
Se houver Partição, escolha entre A e C; Else (operação normal), escolha entre Latência e Consistência.
Isso captura o que o CAP deixa de fora: mesmo sem partição, garantir consistência forte custa latência, porque exige coordenação entre nós.
Trade-offs
| Escolha | Ganha | Perde | Exemplos |
|---|---|---|---|
| CP | Dado sempre correto | Indisponível durante partição | ZooKeeper, etcd, HBase, MongoDB (padrão) |
| AP | Sempre responde | Leitura pode estar desatualizada | Cassandra, DynamoDB, Riak, DNS |
A decisão não é técnica, é de negócio: qual falha custa mais caro — recusar a operação ou aceitar dado divergente?
Vale também notar que a granularidade é por operação, não por sistema. O mesmo produto pode ser CP para "processar pagamento" e AP para "exibir contador de curtidas".
Exemplo prático
Um carrinho de compras durante uma partição entre datacenters:
Escolha AP (a da Amazon, documentada no paper do Dynamo): aceite o item no carrinho mesmo sem conseguir confirmar com o outro lado. Se houver divergência, una os carrinhos depois — no pior caso o cliente remove um item duplicado. Recusar a adição custaria vendas.
Escolha CP para o débito da conta: se não dá para confirmar o saldo, recuse a transação. Um cliente irritado é mais barato que saldo negativo replicado.
O mesmo sistema, duas operações, dois lados do teorema.
Relacionado
Parte de Availability vs Consistency · roadmap.sh/system-design