ACID vs BASE: duas filosofias, um mesmo problema

Toda vez que um sistema grava um dado, surge uma pergunta central para a arquitetura: o que deve acontecer se algo falhar no meio do processo?

Para responder a essa questão, a área de bancos de dados desenvolveu duas filosofias distintas: ACID e BASE.

Mais do que simples siglas técnicas, elas representam abordagens diferentes sobre quais garantias devem receber maior prioridade em um sistema.

De um lado, temos a busca por fortes garantias transacionais e de consistência. Do outro, encontramos arquiteturas distribuídas que priorizam disponibilidade, escalabilidade e capacidade de continuar operando mesmo diante de falhas parciais.

Portanto, escolher entre essas abordagens não significa decidir qual é "melhor", mas entender qual conjunto de garantias atende melhor aos requisitos da aplicação.

O modelo ACID

ACID representa quatro propriedades fundamentais associadas às transações: Atomicity, Consistency, Isolation e Durability.

Essas propriedades são especialmente importantes em sistemas nos quais uma operação precisa manter a integridade dos dados mesmo diante de concorrência ou falhas.

Atomicity — Atomicidade

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

Imagine uma transferência bancária em que R$ 500 são retirados de uma conta e adicionados a outra.

Não faria sentido o sistema concluir apenas o débito e interromper a operação antes de realizar o crédito.

A atomicidade garante que essas operações sejam tratadas como uma única unidade lógica.

Consistency — Consistência

Após uma transação, o banco deve permanecer em um estado válido, respeitando regras de negócio, restrições e integridade dos dados.

Isso significa que uma operação não deve deixar o banco em uma situação que viole as regras estabelecidas pelo sistema.

Isolation — Isolamento

Transações executadas simultaneamente não devem interferir de forma inadequada umas nas outras.

O isolamento controla como uma transação enxerga alterações realizadas por outras transações, evitando problemas causados por concorrência.

Em termos práticos, múltiplos usuários podem utilizar o sistema ao mesmo tempo sem que uma operação comprometa indevidamente o resultado de outra.

Durability — Durabilidade

Depois que uma transação é confirmada com commit, seus efeitos devem permanecer mesmo após uma falha do sistema.

Isso é essencial em aplicações que não podem simplesmente perder uma operação depois de informar ao usuário que ela foi concluída.

É justamente esse conjunto de garantias que torna o modelo ACID tão importante em sistemas como bancos, pagamentos, reservas e controle de estoque.

O modelo BASE

BASE surgiu como uma abordagem associada a sistemas distribuídos de larga escala, nos quais disponibilidade, escalabilidade e tolerância a falhas distribuídas podem ser prioridades importantes.

BASE representa: Basically Available, Soft State e Eventually Consistent.

Basically Available — Basicamente Disponível

O sistema busca continuar respondendo mesmo quando parte da infraestrutura apresenta problemas.

Isso pode significar que uma resposta seja parcial ou que determinados dados ainda não estejam totalmente atualizados em todos os nós.

Soft State — Estado Suave

O estado armazenado pode mudar ao longo do tempo como consequência da sincronização e propagação das informações entre diferentes nós.

Em outras palavras, o estado observado por um nó pode mudar mesmo sem uma nova ação direta do usuário, à medida que as informações são replicadas.

Eventually Consistent — Consistência Eventual

Diferentes nós podem apresentar temporariamente versões diferentes de um dado.

Porém, na ausência de novas alterações, o sistema tende a convergir para um estado consistente.

Esse comportamento aparece em diversos sistemas distribuídos. O DynamoDB, por exemplo, oferece leituras eventualmente consistentes como comportamento padrão em vários cenários, além de também disponibilizar leituras fortemente consistentes.

Isso mostra uma característica importante: um banco distribuído não precisa estar preso a apenas um nível de consistência.

ACID vs BASE

Comparando os dois modelos

Aspecto	ACID	BASE
Prioridade	Consistência e garantias transacionais	Disponibilidade e escalabilidade
Consistência	Fortes garantias dentro da transação	Pode ser eventual
Modelo	Transacional	Distribuído
Escalabilidade	Depende da arquitetura e do banco	Frequentemente orientada à escala horizontal
Aplicações típicas	Finanças, estoque, reservas e faturamento	Feeds, IoT, métricas e sistemas distribuídos

Quando escolher ACID?

ACID costuma ser a escolha mais adequada quando uma inconsistência pode gerar consequências financeiras, operacionais ou legais.

Pense em situações como:

• Transferências bancárias
• Controle de estoque
• Processamento de pagamentos
• Sistemas de reservas
• Faturamento

Nesses cenários, não basta o sistema continuar funcionando. Ele precisa preservar corretamente o estado dos dados.

Imagine um sistema de reservas que permite que duas pessoas reservem exatamente o mesmo assento porque os dados estavam temporariamente inconsistentes.

Nesse contexto, priorizar garantias de consistência pode ser muito mais importante do que aceitar pequenas defasagens para obter maior disponibilidade.

Quando escolher BASE?

BASE tende a fazer mais sentido quando o sistema precisa operar em larga escala e pequenas diferenças temporárias entre réplicas são aceitáveis.

Alguns exemplos incluem:

• Feeds de redes sociais
• Sistemas de recomendação
• Métricas de aplicações
• Processamento de eventos
• Aplicações IoT

Imagine o número de curtidas de uma publicação em uma rede social. Não necessariamente todas as réplicas precisam mostrar o mesmo número no mesmo milissegundo.

Nesse tipo de cenário, pode ser mais interessante manter o serviço disponível e permitir que os dados sejam sincronizados gradualmente.

O DynamoDB, por exemplo, oferece leituras eventualmente consistentes e também permite solicitar leituras fortemente consistentes em determinados contextos.

ACID e BASE não são extremos absolutos

Um ponto importante é evitar a ideia de que um banco é simplesmente "ACID" ou "BASE" em qualquer situação.

Sistemas modernos podem oferecer diferentes níveis de consistência, isolamento e disponibilidade dependendo da operação e da configuração.

O MongoDB, por exemplo, possui diferentes níveis de read concern, permitindo ajustar as garantias de consistência e isolamento das leituras conforme as necessidades da aplicação.

Portanto, a realidade arquitetural é mais complexa do que escolher uma única sigla para representar todo o sistema.

Relação com o Teorema CAP

A discussão sobre ACID e BASE também se conecta ao Teorema CAP, um conceito fundamental para entender sistemas distribuídos.

O CAP considera três propriedades:

• Consistency — Consistência
• Availability — Disponibilidade
• Partition Tolerance — Tolerância a Partições

Em um sistema distribuído sujeito a uma partição de rede, a arquitetura precisa lidar com o trade-off entre consistência e disponibilidade.

É nesse contexto que a filosofia BASE aparece com frequência: aceitar determinados níveis de consistência eventual pode permitir que o sistema continue disponível durante situações em que a comunicação entre os nós está comprometida.

Já sistemas que precisam preservar garantias de consistência mais fortes podem optar por reduzir determinadas formas de disponibilidade durante uma falha.

Os dois modelos podem coexistir

Uma das ideias mais importantes para arquitetura de sistemas modernos é que ACID e BASE não precisam competir dentro de uma mesma aplicação.

É perfeitamente possível utilizar diferentes tecnologias e estratégias dependendo da função que cada componente exerce.

Um sistema pode utilizar um banco relacional para:

• Contas financeiras
• Autenticação
• Pagamentos
• Faturamento

Enquanto outra solução pode ser utilizada para:

• Cache
• Logs
• Feeds de atividade
• Métricas
• Eventos distribuídos

Dessa forma, cada componente recebe uma estratégia de armazenamento alinhada às suas próprias necessidades.

O verdadeiro trade-off arquitetural

A principal pergunta não deve ser: "ACID é melhor que BASE?"

A pergunta correta é: "Quais garantias meu sistema realmente precisa?"

Se uma inconsistência pode causar prejuízo financeiro, perda de dados ou problemas críticos para o negócio, garantias fortes podem ser indispensáveis.

Por outro lado, se pequenas defasagens são aceitáveis e o sistema precisa suportar milhões de usuários distribuídos globalmente, disponibilidade e escalabilidade podem receber maior prioridade.

Resumindo

ACID → prioriza garantias transacionais e consistência.

BASE → prioriza disponibilidade e escalabilidade, aceitando consistência eventual em determinados cenários.

Nenhuma das duas abordagens é universalmente superior.

A melhor escolha depende dos requisitos do sistema, do impacto das falhas e do nível de consistência que o negócio realmente precisa.

Em arquitetura de software, a tecnologia deve ser consequência dos requisitos — e não o contrário.

E você?
No sistema que está desenvolvendo, você priorizaria consistência, disponibilidade ou buscaria combinar as duas estratégias?

Saiba mais:
PostgreSQL: https://www.postgresql.org/docs/current/tutorial-transactions.html
Amazon DynamoDB - Consistência: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
MongoDB - Read Concern: https://www.mongodb.com/docs/manual/reference/read-concern/