CAP Theorem aplicado
Consistency, Availability, Partition tolerance — escolhas reais por banco, não diagramas abstratos
CAP: em um sistema distribuído você só garante 2 das 3 propriedades simultaneamente. Mas como partições acontecem (rede falha, sempre), a escolha real é entre CP (consistência sob partição) e AP (disponibilidade sob partição). "CA puro" só existe em single-node.
Triângulo CAP
Em uma frase por escolha
| Escolha | Significado | Quando faz sentido |
|---|---|---|
| CP | Sob partição: recusa requests (timeout / erro) em vez de servir dado potencialmente inconsistente | Pagamentos, estoque, saldo, qualquer operação onde "errado" custa mais que "indisponível" |
| AP | Sob partição: continua aceitando requests; aceita servir dado stale entre nós | Feeds, analytics, recomendações, contadores — leitura stale não causa dano sério |
| CA | Não tolera partição — só funciona em single-node ou rede 100% confiável | SQL tradicional sem replicação; cenários de baixa criticidade |
"CAP é binário" é mito. Em sistemas reais a escolha é por operação. Mongo é CP com majority writes mas AP com read concern local. DynamoDB é AP por default mas pode ser CP com strong consistency. Não existe "Mongo é CP" — existe "Mongo configurado dessa forma para essa operação é CP".
O que partição realmente parece
- Switch de rede entre AZs morre por 30s
- Garbage collection pause de 8s no master
- Rebalance de partições no Kafka deixa parte dos consumers cegos
- Cross-region link satura — latência sobe pra 5s, requests timeout
- Replication slot do Postgres lag em 10GB e replica fica "atrás"
Nenhuma dessas é "rede caiu por horas". São microeventos diários em produção. Sistema "CA" simplesmente não existe em multi-node.