PACELC é um framework para classificar sistemas distribuídos que estende o CAP ao incluir o trade-off entre latência e consistência mesmo quando não há falha de rede.
Proposto por Daniel Abadi em 2010 após reconhecer que o CAP descreve apenas o comportamento sob partição, deixando de fora o comportamento cotidiano do sistema.
A estrutura do PACELC
Se há Partição (P):
escolha entre Availability (A) e Consistency (C)
Senão, Else (E):
escolha entre Latency (L) e Consistency (C)
A segunda parte é o que o CAP ignora. Em operação normal, sem falhas, um sistema que exige consistência forte precisa coordenar nós antes de confirmar cada operação. Essa coordenação adiciona latência. Sistemas que evitam essa coordenação respondem mais rápido, mas aceitam que réplicas possam ter dados levemente defasados.
Por que consistência custa latência
Consistência forte (linearizabilidade) exige que, antes de confirmar uma escrita, o nó líder saiba que a maioria das réplicas recebeu o dado. O fluxo é:
Cliente → Líder
Líder → Réplica 1 (aguarda ACK)
Líder → Réplica 2 (aguarda ACK)
Líder → Cliente: "confirmado"
O tempo de resposta inclui obrigatoriamente o round-trip até as réplicas. Em clusters geograficamente distribuídos, isso é medido em dezenas a centenas de milissegundos.
Para reduzir latência, sistemas EL usam replicação assíncrona: o líder confirma para o cliente antes de as réplicas receberem o dado. A escrita pode se perder se o líder falhar antes da propagação.
Cliente → Líder
Líder → Cliente: "confirmado" ← resposta imediata
Líder → Réplica 1 (async, sem esperar)
Líder → Réplica 2 (async, sem esperar)
Modelos de consistência entre forte e eventual
O espectro não é binário. Entre consistência forte e consistência eventual existem modelos intermediários que os sistemas EL usam para dar garantias parciais com latência menor:
Consistência causal: operações relacionadas causalmente são vistas na ordem correta por todos os nós. Operações sem relação causal podem chegar fora de ordem. Se você postou uma foto e depois adicionou uma legenda, nenhum nó vai exibir a legenda sem a foto.
Consistência de sessão (session consistency): dentro de uma mesma sessão de cliente, leituras sempre refletem as escritas do próprio cliente. Outros clientes podem ver versões mais antigas. Útil para evitar que o usuário perca suas próprias edições ao fazer refresh.
Monotonic read consistency: se um cliente leu um valor na versão X, nunca verá uma versão anterior a X em leituras subsequentes. Evita que o feed social “volte no tempo”.
Read-your-writes: todo cliente vê suas próprias escritas imediatamente, mas não necessariamente as escritas de outros. Variação mais restrita da consistência de sessão.
Classificação de bancos reais
| Banco | Sob partição | Sem partição | Raciocínio |
|---|---|---|---|
| DynamoDB | PA | EL | Prioriza disponibilidade e baixa latência por padrão; strongly consistent reads são opt-in e mais lentos |
| Cassandra | PA | EL | Replicação assíncrona por padrão; QUORUM eleva consistência mas aumenta latência |
| Riak | PA | EL | Projetado para disponibilidade máxima; usa CRDTs para resolver conflitos |
| MongoDB | PC | EC | Leitura do primário por padrão; secondary reads são EL explicitamente |
| Zookeeper | PC | EC | Consenso via ZAB antes de qualquer confirmação |
| etcd | PC | EC | Consenso via Raft; usado justamente quando consistência é crítica |
| CockroachDB | PC | EC | Transações distribuídas com consenso Raft por shard |
| Google Spanner | PC | EC | TrueTime garante ordenação global sem sacrificar consistência |
| MySQL (single-node) | N/A | EC | Sem partição por ser não-distribuído; replicação para réplicas é async por padrão |
Quando o “E” importa mais que o “P”
Partições são raras em clusters bem configurados dentro de um datacenter. O que acontece todos os dias é o trade-off EL vs EC: latência de escrita, comportamento de leitura em réplicas, e o que o cliente experimenta durante operação normal.
Ao escolher um banco distribuído, as perguntas práticas são:
- Escrita: o sistema espera ACK da maioria antes de confirmar? (EC) Ou confirma e replica depois? (EL)
- Leitura: sempre vai ao líder? (EC, mais lento) Ou pode ir a qualquer réplica? (EL, mais rápido, potencialmente desatualizado)
- Conflito: se dois nós recebem escritas simultâneas no mesmo dado, quem ganha? Last-write-wins, CRDT, ou o sistema rejeita a segunda escrita?
Conexões
- teorema-cap: base do PACELC; classificação CP vs AP sob partição
- db-nosql: bancos PA/EL (Cassandra, DynamoDB) e PC/EC (MongoDB, Zookeeper) na prática
- gcp-spanner: caso especial de PC/EC com consistência global via TrueTime
- gcp-bigtable: PA/EL com consistência eventual entre regiões
- gcp-firestore: sessão de consistência configurável por operação
Referências
- Daniel Abadi, Problems with CAP, and Yahoo’s little known NoSQL system (2010)
- Daniel Abadi, Consistency Tradeoffs in Modern Distributed Database System Design (2012, IEEE Computer)
- Martin Kleppmann, Designing Data-Intensive Applications, cap. 9 (modelos de consistência)
- Kyle Kingsbury (Jepsen), testes empíricos de consistência em bancos reais: https://jepsen.io/analyses