diogodev_

Voltar à listagem

Conteúdo

PACELC: Como escolher um banco de dados entendendo os trade-offs reais

Quando falamos sobre bancos de dados, uma das perguntas mais comuns é: "Qual é o melhor banco de dados?" A resposta quase sempre é: depende do problema que você está tentando resolver. Não existe um banco perfeito para todos os cenários. Cada tecnologia faz escolhas diferentes entre consistência, disponibilidade e latência. É justamente aí que entra um dos conceitos mais importantes da arquitetura distribuída: o Teorema PACELC.

Antes do PACELC: o Teorema CAP

Provavelmente você já ouviu falar do CAP Theorem, que diz que, durante uma falha de rede (Partition), um sistema distribuído precisa escolher entre:

  • Consistency (C) — todos os nós enxergam os mesmos dados.
  • Availability (A) — toda requisição recebe uma resposta.
  • Partition Tolerance (P) — o sistema continua funcionando mesmo com falhas de comunicação.

O problema é que o CAP só fala sobre quando existe uma partição de rede.

Mas... e quando tudo está funcionando normalmente?

Foi justamente para responder essa pergunta que surgiu o PACELC.

O que é o Teorema PACELC?

O pesquisador Daniel J. Abadi propôs uma extensão do CAP conhecida como PACELC.

A ideia é simples:

Se ocorrer uma partição (P), escolha entre Availability (A) ou Consistency (C).

Else (E), quando não houver partição, escolha entre Latency (L) ou Consistency (C).

Daí vem o nome:

PA/EL

ou

PC/EC

Dependendo das escolhas feitas pelo banco.

Em outras palavras:

  • Durante falhas, existe um trade-off entre disponibilidade e consistência.
  • Em condições normais, existe um trade-off entre baixa latência e consistência forte.

Esse segundo ponto é o que torna o PACELC muito mais útil na prática.

Visualizando o PACELC

Existe partição?

        Sim
         |
         |
   Consistência?
      /       \
     C         A

        Não
         |
         |
 Latência?
      /      \
     L        C

Os principais perfis

PA/EL

Durante partições:

  • prioriza disponibilidade.

Sem partições:

  • prioriza baixa latência.

Ideal para sistemas que precisam responder rapidamente.

PA/EC

Durante partições:

  • prioriza disponibilidade.

Sem partições:

  • prefere consistência.

É um perfil mais raro.

PC/EL

Durante partições:

  • prioriza consistência.

Sem partições:

  • busca baixa latência.

Alguns bancos configuráveis podem operar próximos desse modelo.

PC/EC

Durante partições:

  • prioriza consistência.

Sem partições:

  • continua priorizando consistência, mesmo aumentando a latência.

É o modelo mais conservador.

Comparando quatro bancos populares

PostgreSQL

O PostgreSQL é um banco relacional focado em ACID.

Sua prioridade é garantir que os dados estejam corretos.

Isso significa que:

  • uma escrita precisa ser confirmada;
  • transações são consistentes;
  • integridade referencial é mantida.

O preço disso é uma latência um pouco maior em ambientes distribuídos.

Quando usar

  • ERP
  • Sistemas financeiros
  • E-commerce
  • Controle de estoque
  • Pagamentos

Se perder um pedido ou duplicar um pagamento é inaceitável, PostgreSQL é uma excelente escolha.

Cassandra

O Cassandra foi criado para operar em centenas ou milhares de servidores.

Seu foco é:

  • disponibilidade;
  • escalabilidade;
  • escrita extremamente rápida.

Ele aceita que alguns nós possam ainda não ter recebido a informação.

Isso significa que, durante um curto período, usuários diferentes podem enxergar valores diferentes.

Essa abordagem é conhecida como consistência eventual.

Quando usar

  • Logs
  • IoT
  • Telemetria
  • Redes sociais
  • Grandes volumes de eventos

Empresas como Netflix utilizam Cassandra justamente por conseguir continuar funcionando mesmo diante de falhas.

MongoDB

O MongoDB trabalha com documentos JSON e possui uma arquitetura bastante flexível.

Ele permite configurar diferentes níveis de consistência através de:

  • Write Concern
  • Read Concern
  • Read Preference

Na prática, isso significa que você consegue adaptar o banco ao seu cenário.

Pode escolher mais performance ou mais consistência dependendo da necessidade.

Quando usar

  • CMS
  • Catálogos
  • APIs
  • Sistemas cujo modelo muda frequentemente

DynamoDB

O DynamoDB foi criado pela AWS para oferecer escalabilidade automática.

Você praticamente não precisa administrar servidores.

Ele consegue atender milhões de requisições por segundo mantendo baixa latência.

Em troca, adota consistência eventual por padrão (embora permita leituras fortemente consistentes em muitos cenários).

Quando usar

  • Serverless
  • Microsserviços
  • APIs de alta escala
  • Sessões de usuários
  • Jogos online

É muito comum em arquiteturas totalmente baseadas em serviços da AWS.

Então qual banco escolher?

A escolha depende do tipo de problema.

A pior decisão é escolher um banco apenas porque ele está "na moda".

Primeiro entenda:

  • Qual volume de dados você terá?
  • Quantas escritas por segundo?
  • Qual latência é aceitável?
  • Você pode tolerar consistência eventual?
  • Quanto custa ficar indisponível?

Essas perguntas normalmente definem a resposta antes mesmo de olhar para qualquer tecnologia.

Conclusão

O PACELC nos lembra que todo banco de dados faz concessões.

Não existe uma solução que entregue simultaneamente:

  • máxima consistência;
  • máxima disponibilidade;
  • menor latência;
  • escalabilidade infinita.

Cada banco foi projetado para otimizar um conjunto diferente de prioridades.

Entender o PACELC permite tomar decisões arquiteturais mais conscientes, justificando tecnicamente por que um banco relacional faz sentido em um sistema financeiro, enquanto um banco distribuído como Cassandra ou DynamoDB é mais adequado para aplicações de alta escala.

Na arquitetura de software, escolher um banco de dados não é sobre encontrar "o melhor". É sobre escolher aquele cujos trade-offs estão alinhados às necessidades do seu sistema.

Saiba mais