diogodev_

Voltar à listagem

Conteúdo

ACID vs BASE: entendendo os dois modelos de consistência em bancos de dados

Ao projetar um sistema distribuído, uma das decisões mais importantes envolve a escolha do banco de dados e do modelo de consistência que ele oferece. Não existe uma solução universal: tudo depende dos requisitos do negócio.

É comum ouvir que bancos relacionais utilizam ACID, enquanto bancos NoSQL seguem o modelo BASE. Embora essa associação seja verdadeira na maioria dos casos, entender o que cada um representa ajuda a tomar decisões arquiteturais muito melhores.

Neste artigo vamos entender o significado de ACID e BASE, suas diferenças, vantagens, desvantagens e quando utilizar cada abordagem.

O que é ACID?

O modelo ACID é um conjunto de propriedades que garantem que uma transação seja executada de forma segura e consistente.

Ele é encontrado principalmente em bancos relacionais como:

  • PostgreSQL
  • Oracle Database
  • Microsoft SQL Server
  • MySQL
  • MariaDB

Seu principal objetivo é garantir que os dados permaneçam corretos mesmo diante de falhas, concorrência ou interrupções inesperadas.

É por isso que sistemas financeiros normalmente utilizam bancos ACID.

A — Atomicidade (Atomicity)

Uma transação deve ser executada por completo ou não ser executada.

Não existe meio termo.

Imagine uma transferência via PIX:

  1. Debitar R$100 da conta A.
  2. Creditar R$100 na conta B.

Se ocorrer uma falha após o débito e antes do crédito, toda a operação deve ser cancelada.

Caso contrário, o dinheiro simplesmente desapareceria.

Essa é a garantia da atomicidade.

C — Consistência (Consistency)

Toda transação deve respeitar todas as regras de negócio.

Os dados nunca podem terminar em um estado inválido.

Exemplo:

Um estoque possui 3 unidades.

Duas vendas acontecem simultaneamente.

O banco nunca pode permitir que o estoque termine em -1.

As restrições, chaves estrangeiras, validações e regras de integridade precisam sempre ser preservadas.

I — Isolamento (Isolation)

Transações simultâneas não podem interferir umas nas outras.

Imagine um show com apenas um ingresso restante.

Duas pessoas clicam em "Comprar" exatamente no mesmo instante.

Sem isolamento, ambas poderiam concluir a compra.

Com ACID, apenas uma transação consegue reservar o ingresso.

A outra receberá uma mensagem informando que o produto já foi vendido.

Esse comportamento é controlado por mecanismos como bloqueios (locks) e níveis de isolamento.

D — Durabilidade (Durability)

Depois que uma transação é confirmada (commit), ela nunca pode ser perdida.

Mesmo que ocorra:

  • queda de energia;
  • reinicialização do servidor;
  • falha do banco de dados.

Os dados continuam persistidos.

Essa garantia normalmente é obtida através de mecanismos como Write Ahead Log (WAL), redo logs e replicação.

Onde ACID é utilizado?

Sistemas que não podem correr o risco de inconsistências normalmente utilizam bancos relacionais.

Alguns exemplos:

  • sistemas bancários;
  • pagamentos (PIX, cartão, TED);
  • e-commerce (pedidos);
  • controle de estoque;
  • emissão de notas fiscais;
  • reserva de passagens;
  • venda de ingressos;
  • ERPs.

Nesses cenários, perder dados ou permitir inconsistências pode gerar prejuízos financeiros.

O que é BASE?

O modelo BASE surgiu para resolver outro problema: escalabilidade.

Em aplicações distribuídas com milhões de usuários, garantir consistência imediata em todos os servidores pode reduzir drasticamente o desempenho.

Por isso, muitos bancos NoSQL adotam uma filosofia diferente.

Alguns exemplos:

  • MongoDB
  • Cassandra
  • DynamoDB
  • Couchbase
  • Riak

O foco deixa de ser consistência imediata e passa a ser disponibilidade e alta escalabilidade.

BA — Basically Available

O sistema procura sempre responder às requisições.

Mesmo que alguma réplica esteja indisponível, outra poderá atender.

O objetivo é manter a aplicação funcionando.

É melhor responder com uma informação um pouco antiga do que não responder.

S — Soft State

O estado do sistema é considerado fluido.

Como existem diversas réplicas distribuídas, elas podem estar temporariamente diferentes umas das outras.

Durante a sincronização, cada servidor pode possuir uma visão diferente dos dados.

Esse comportamento é esperado.

E — Eventual Consistency

Os dados podem ficar temporariamente inconsistentes.

Após algum tempo, todas as réplicas convergem para o mesmo estado.

Esse intervalo pode durar:

  • alguns milissegundos;
  • alguns segundos;
  • ou até minutos, dependendo da arquitetura.

Exemplo

Imagine uma rede social.

Você publica uma foto.

Seu amigo acessa imediatamente.

É possível que ele ainda não veja a publicação porque a réplica que atendeu sua requisição ainda não recebeu a atualização.

Poucos segundos depois, tudo estará sincronizado.

Essa é a consistência eventual.

Onde BASE é utilizado?

BASE é muito comum em aplicações que precisam suportar enormes volumes de acesso.

Alguns exemplos:

  • redes sociais;
  • sistemas de recomendação;
  • analytics;
  • armazenamento de logs;
  • cache distribuído;
  • telemetria;
  • monitoramento;
  • catálogos de produtos.

Nesses casos, uma pequena demora na propagação dos dados geralmente não causa impacto para o usuário.

Quando escolher cada um?

Escolha ACID quando:

  • dinheiro está envolvido;
  • não pode haver inconsistências;
  • existe controle de estoque;
  • há reservas de recursos;
  • regras de negócio precisam ser rigorosamente respeitadas.

Escolha BASE quando:

  • disponibilidade é prioridade;
  • o sistema precisa escalar horizontalmente;
  • pequenas inconsistências temporárias são aceitáveis;
  • o volume de leitura é muito alto;
  • a aplicação é distribuída globalmente.

É possível usar os dois?

Sim.

Na verdade, essa é uma das arquiteturas mais comuns atualmente.

Por exemplo, um e-commerce pode utilizar:

  • PostgreSQL para pedidos, pagamentos e estoque (ACID);
  • Redis para cache;
  • MongoDB para catálogo de produtos;
  • Elasticsearch para pesquisas;
  • DynamoDB ou Cassandra para eventos e telemetria.

Cada banco resolve um problema específico.

A arquitetura moderna valoriza o uso da ferramenta mais adequada para cada necessidade, em vez de tentar resolver tudo com um único banco de dados.

Conclusão

ACID e BASE não são tecnologias concorrentes, mas modelos que atendem necessidades diferentes.

O modelo ACID oferece garantias rigorosas de consistência e é ideal para operações críticas, como pagamentos, controle de estoque e sistemas financeiros.

Já o modelo BASE prioriza disponibilidade, escalabilidade e desempenho, sendo uma excelente escolha para aplicações distribuídas de grande porte, como redes sociais, sistemas de recomendação e plataformas de analytics.

A escolha entre eles deve considerar os requisitos do negócio. Em muitos sistemas modernos, a melhor solução é combinar ambos os modelos, utilizando bancos relacionais para dados críticos e bancos NoSQL para cargas de trabalho que exigem alta escala e disponibilidade.

Saiba mais