Esse artigo é um complemento ao capítulo anterior sobre ACID, BASE e Teorema CAP, e apresenta uma evolução conceitual do modelo teórico do CAP, incluindo as críticas que surgiram com a evolução dos sistemas distribuídos e de seus componentes. O PACELC é um conceito mais moderno, que ajuda a compreender algumas lacunas que o CAP não cobre.

Após uma boa assimilação das classificações AP, CA, CP do CAP, podemos aprofundar o entendimento nos apêndices trazidos pelo PACELC.

O Teorema PACELC

O Teorema PACELC foi proposto por Daniel Abadi em 2010, na Universidade de Yale, e nos ajuda a entender sistemas distribuídos para além do que é proposto pelo Teorema CAP. O Teorema CAP, como já vimos, estabelece que um sistema, mediante uma partição de rede, precisa escolher entre consistência e disponibilidade. Esse modelo foi — e ainda é — extremamente importante para nortear decisões arquiteturais e de engenharia em diversos contextos, mas deixa algumas lacunas conceituais em sistemas modernos, principalmente quanto ao comportamento do sistema ao considerar a Partition Tolerance. Por exemplo: o que aconteceria com um sistema quando não houver falhas de rede?

O PACELC amplia esse entendimento no contexto de bancos de dados distribuídos ao levantar uma nova questão: o que acontece quando não há falhas de rede e não há particionamento entre os nós do sistema? Nesses cenários, é possível operar em diferentes níveis de consistência conforme a necessidade. Assim, o modelo nos ajuda a refletir: o que o sistema deve priorizar quando está funcionando corretamente? E, de forma complementar, o que ele deve priorizar quando ocorre um particionamento entre os nós? O teorema nos ajuda a responder esses questionamentos de forma mais detalhado.

Teorema PACELC vs Teorema CAP

Como vimos anteriormente, o Teorema CAP diz que quando ocorre uma Partição de Rede (P) entre os nós do sistema, é necessário escolher entre Consistência (C) ou Disponibilidade (A). Esse raciocínio é muito útil para a escolha de tecnologias que envolvem esses dois trade-offs, mas ainda deixa em aberto o requisito não funcional de como o sistema deve operar quando não há partições de rede.

O PACELC funciona como uma extensão do CAP, propondo o seguinte racional: se houver partição (P), devemos escolher entre Disponibilidade (A) e Consistência (C); Else (E), ou seja, se não houver partição, escolhemos entre Latência (L) e Consistência (C). O teorema mostra que, mesmo em condições normais, sem partições —, ainda é preciso tomar decisões difíceis ao projetar a arquitetura. Ou priorizamos a garantia de uma consistência forte, pagando o preço de mais latência, ou abrimos mão de maiores níveis de consistência para reduzir o tempo de resposta e otimizar a performance das operações.

Em momentos de falha, decidimos entre disponibilidade e consistência. Fora deles, optamos entre consistência forte, que pode custar latência, e consistência eventual, que otimiza a performance mas sem garantias imediatas de consistência.

Esse raciocínio aproxima o modelo da realidade dos sistemas modernos, onde temos redes geograficamente distribuídas, replicação de dados e sharding e particionamento.

Imagine um banco de dados global: se ele quiser garantir que todas as réplicas estejam sempre sincronizadas antes de confirmar uma operação (consistência forte), cada escrita será mais lenta devido à latência de rede. Já se ele aceitar consistência eventual, poderá responder mais rápido, mas correrá o risco de que um usuário no Brasil veja um dado diferente de outro usuário na Espanha por algum tempo.

Em resumo, os dois teoremas não são excludentes, mas complementares. O PACELC amplia o CAP ao analisar não apenas os cenários de falha, mas também o comportamento do sistema em situações normais, conectando os padrões CP (Consistency + Partition Tolerance) e AP (Availability + Partition Tolerance) com as escolhas de Latência (L) e Consistência (C) fora das partições.

Aplicações do PACELC

O Teorema PACELC se tornou uma forma prática de classificar sistemas distribuídos e suas bases de dados. Por exemplo, o Amazon DynamoDB é conhecido como PA/EL — ou seja, prefere disponibilidade durante partições (PA) e latência baixa em condições normais (EL). Já o Google Spanner é classificado como PC/EC, pois prefere consistência tanto durante partições quanto no funcionamento cotidiano, aceitando pagar o preço da latência.

Assim como no CAP, em que temos classificações como AP, CP ou AC, no PACELC também é possível categorizar os bancos de dados em diferentes combinações, como PA/EL, PC/EL, PA/EC e PC/EC, dependendo das escolhas de tr

PA/EL (On Partition, Availability; Else, Latency)

O modelo PA/EL descreve um sistema que, em condições normais (sem partição de rede), prioriza a latência em vez da consistência. Esse tipo de sistema busca garantir baixa latência nas operações, mesmo que isso signifique abrir mão de uma consistência forte. Else (E): quando ocorre uma partição de rede, o sistema prioriza a disponibilidade (A) em vez da consistência (C). Em outras palavras, reforça o modelo de consistência eventual, no qual todos os nós continuam respondendo às requisições independentemente do rompimento da partição, ainda que as réplicas não estejam totalmente sincronizadas.

Esses bancos de dados são projetados para oferecer alta performance nas operações de escrita de forma resiliente, mas aceitam que diferentes usuários possam ver versões ligeiramente diferentes dos dados por algum tempo, até que a partição seja resolvida. É o caso de tecnologias como DynamoDB e Cassandra, amplamente utilizadas em cenários de grande escala, onde performance global e disponibilidade são mais importantes que a consistência absoluta.

PC/EL (On Partition, Consistency; Else, Latency)

No modelo PC/EL, temos sistemas que, em seu funcionamento normal, priorizam a latência e o alto throughput ao custo da consistência. Nesse cenário, o sistema reduz o nível de consistência operacional para manter tempos de resposta rápidos e operações de escrita otimizadas.

Else (E): em caso de particionamento, o sistema passa a priorizar a consistência (C). Isso significa que, em uma situação de falha, o sistema pode ficar indisponível até que o cluster recupere o consenso e volte a operar, garantindo a integridade dos dados mesmo ao custo da disponibilidade temporária.

É uma escolha intermediária, onde os sistemas em questão não possuem soluções confiáveis de resolução de conflitos em grandes volumes de dados, funcionando apenas dentro do fluxo transacional previsto. Por isso, é preferível tornar o serviço indisponível do que lidar com uma parcela de dados que eventualmente nunca se tornariam consistentes.

Esse modelo é interessante quando a consistência mínima durante falhas é inegociável, mas, durante a operação normal, o objetivo é priorizar alto desempenho nas operações de escrita e leitura. O sistema aceita consistência eventual apenas quando todos os nós estão disponíveis, exigindo processos contínuos de health checks e heartbeats entre eles para validar o status antes de realizar operações. Caso contrário, prefere ficar totalmente inoperante.

PA/EC (On Partition, Availability; Else, Consistency)

O modelo PA/EC descreve sistemas que, em condições normais de operação, priorizam a consistência forte, garantindo que todas as réplicas do sistema mantenham sempre a mesma versão do dado.

Else (E): em caso de falhas ou particionamentos de rede, o sistema prioriza a disponibilidade (A), aceitando operações de escrita e leitura mesmo que existam divergências temporárias entre as réplicas.

Normalmente, esses sistemas contam com algoritmos complexos de CRDTs (Conflict-Free Replicated Data Types), que fazem a gestão de conflitos entre diferentes atualizações de dados em nós distribuídos. Esse modelo é menos comum, mas pode aparecer em contextos híbridos de microserviços, nos quais a experiência do usuário não pode parar mesmo com falhas parciais, mas em que a regra de negócio e a criticidade operacional exigem que, quando a rede está saudável, todos os dados permaneçam rigorosamente sincronizados.

Em resumo, esse modelo assume a consistência eventual apenas como um fallback da consistência forte em último caso.

PC/EC (On Partition, Consistency; Else, Consistency)

O modelo PC/EC descreve sistemas que são mais conservadores em relação à consistência dos dados. em operações normais, o sistema também prioriza a consistência em vez da latência, aceitando um maior custo de tempo de resposta em troca da garantia de que a última versão do dado esteja disponível em todos os nós. ELSE; Durante uma partição de rede, o sistema prioriza a consistência (C) em vez da disponibilidade (A), assumindo que é melhor falhar temporariamente do que operar com consistência eventual em algum nível.

Esse comportamento é típico em sistemas nos quais a precisão dos dados é a qualidade mais importante. É a escolha natural para sistemas bancários, coordenação de clusters e transações críticas, onde ver dados incorretos por alguns milissegundos pode gerar prejuízos enormes.

Podemos encontrar esse modelo em bancos SQL tradicionais, no etcd e também em bancos transacionais geograficamente distribuídos, como o Google Spanner.

Comparações do PACELC

A seguir, temos uma tabela comparativa de alguns flavors de bancos ditribuídos que estão inerentes a trabalhos com partição, e onde cada uma delas se encontra dentro dos itens do PACELC.

Referências

Consistency Tradeoffs in Modern Distributed Database System Design

PACELC design principle

PACELC: A extensão do Teorema CAP

PACELC Theorem

PACELC Theorem Explained: Distributed Systems Series

System Design Interview Basics: CAP vs. PACELC

PACELC Theorem

PACELC Theorem & Distributed Databases

Understanding Eventual Consistency in DynamoDB