ACID vs BASE: consistência forte ou disponibilidade em sistemas distribuídos?
Quando a gente começa a estudar banco de dados e System Design, uma hora aparece uma comparação bem importante:
ACID vs BASE
À primeira vista, parece só mais uma sigla para decorar. Mas, na prática, esse assunto explica uma das decisões mais importantes no desenho de sistemas: priorizar consistência forte ou priorizar disponibilidade e escala.
E essa escolha muda completamente a forma como uma aplicação se comporta em cenários reais.
O que é ACID?
ACID é um conjunto de propriedades usado principalmente em bancos relacionais e sistemas transacionais.
A ideia do ACID é garantir que as operações no banco aconteçam com segurança, previsibilidade e integridade.
ACID significa:
Atomicity
Consistency
Isolation
Durability
Em português:
Atomicidade
Consistência
Isolamento
Durabilidade
1. Atomicity
Atomicidade significa que uma transação é indivisível.
Ou tudo acontece com sucesso, ou nada acontece.
Imagine uma transferência bancária:
Conta A envia R$100 para Conta B
Essa operação envolve, no mínimo:
1. Remover R$100 da Conta A
2. Adicionar R$100 na Conta B
Se o sistema conseguir remover o dinheiro da Conta A, mas falhar antes de adicionar na Conta B, o banco de dados ficaria inconsistente.
Com atomicidade, isso não pode acontecer.
Ou as duas operações são concluídas, ou a transação inteira é desfeita.
Tudo ou nada.
2. Consistency
Consistência, no contexto do ACID, significa que uma transação deve levar o banco de dados de um estado válido para outro estado válido.
Ou seja, as regras do banco precisam continuar sendo respeitadas.
Essas regras podem ser:
- chaves estrangeiras;
- constraints;
- validações;
- triggers;
- regras de integridade;
- regras de domínio.
Exemplo:
Um pedido não pode existir sem um usuário válido.
Se existe uma regra dizendo que todo pedido precisa estar ligado a um usuário, o banco não deve aceitar um pedido apontando para um usuário inexistente.
A consistência do ACID não é exatamente a mesma coisa que “todos os nós distribuídos veem o mesmo dado ao mesmo tempo”. Essa segunda ideia aparece mais no contexto de sistemas distribuídos e CAP Theorem.
3. Isolation
Isolamento significa que transações simultâneas não devem interferir incorretamente umas nas outras.
Imagine duas pessoas tentando comprar o último ingresso de um evento ao mesmo tempo.
Sem isolamento, as duas transações poderiam ler o mesmo estoque disponível e ambas finalizar a compra.
Com isolamento, o banco controla a concorrência para evitar esse tipo de problema.
A ideia é:
Uma transação não deve enxergar efeitos parciais ou inconsistentes de outra transação.
Na prática, bancos podem trabalhar com diferentes níveis de isolamento, como:
- Read Uncommitted;
- Read Committed;
- Repeatable Read;
- Serializable.
Quanto mais forte o isolamento, maior a segurança contra anomalias de concorrência. Por outro lado, também pode existir impacto em performance.
4. Durability
Durabilidade significa que, depois que uma transação foi confirmada, os dados precisam permanecer salvos mesmo se acontecer uma falha.
Exemplos de falha:
- queda de energia;
- crash da aplicação;
- reinício do servidor;
- falha inesperada no processo do banco.
Se o banco confirmou uma transação com sucesso, ele precisa garantir que aquela alteração não será perdida.
Commit feito, dado persistido.
Onde ACID faz sentido?
ACID é muito importante quando a integridade dos dados é crítica.
Exemplos:
- sistemas bancários;
- pagamentos;
- ERPs;
- sistemas contábeis;
- controle de estoque;
- marketplaces;
- sistemas de reserva;
- aplicações financeiras.
Em uma transferência bancária, não dá para aceitar “consistência depois”.
O saldo precisa estar correto.
Em um controle de estoque, também não é aceitável vender o mesmo item várias vezes se só existe uma unidade disponível.
Nesses casos, consistência forte e segurança transacional são prioridades.
O que é BASE?
BASE é um modelo muito comum em sistemas distribuídos que precisam priorizar disponibilidade, escalabilidade e tolerância a falhas.
BASE significa:
Basically Available
Soft State
Eventual Consistency
Enquanto o ACID tenta garantir consistência forte durante as transações, o BASE aceita que os dados possam ficar temporariamente inconsistentes em troca de maior disponibilidade.
Uma forma simples de pensar é:
ACID: consistência forte agora.
BASE: disponibilidade agora, consistência depois.
1. Basically Available
Basically Available significa que o sistema tenta responder às requisições mesmo quando parte da infraestrutura está com problema.
A resposta pode não conter o dado mais atualizado possível, mas o sistema continua funcionando.
Exemplo:
Você posta uma foto em uma rede social.
Talvez alguns amigos vejam a foto imediatamente. Outros talvez só vejam alguns segundos depois, porque a atualização ainda está sendo propagada entre servidores, regiões ou réplicas.
Mesmo assim, o sistema continua disponível:
- você consegue acessar o app;
- o feed carrega;
- as requisições recebem resposta;
- algumas informações podem aparecer com atraso.
A ideia aqui é:
Availability e uptime > consistência imediata.
2. Soft State
Soft State significa que o estado do sistema pode mudar ao longo do tempo, mesmo sem uma nova ação direta do usuário.
Isso acontece porque os dados podem estar sendo replicados, sincronizados ou atualizados de forma assíncrona.
Exemplo:
Você abre uma tela de pedido e vê:
Pedido em separação
Alguns segundos depois, sem clicar em nada, a tela muda para:
Pedido enviado
Isso pode acontecer porque outro serviço atualizou o pedido, e essa atualização foi propagada depois.
Ou seja, o estado do sistema não é completamente rígido naquele instante. Ele pode estar em transição.
3. Eventual Consistency
Eventual Consistency significa que os dados podem ficar inconsistentes por um período, mas eventualmente convergem para o mesmo estado.
Exemplo:
Você altera seu nome de perfil de:
Luis
para:
Luis Fernando
Em uma região, o novo nome já aparece atualizado.
Em outra região, por alguns segundos, ainda aparece o nome antigo.
Depois de algum tempo, todas as réplicas recebem a atualização e passam a mostrar o mesmo valor.
Isso é consistência eventual.
Os dados podem divergir temporariamente,
mas convergem com o tempo.
Essa propagação pode acontecer por:
- filas;
- eventos;
- replicação;
- workers;
- sincronização entre nós;
- processamento assíncrono.
ACID vs BASE na prática
A diferença principal não é que um é certo e o outro é errado.
A diferença é o tipo de problema que cada modelo tenta resolver.
ACID
ACID é melhor quando o sistema não pode aceitar inconsistência.
Exemplo:
Uma transferência bancária não pode remover dinheiro de uma conta
sem adicionar na outra.
Outro exemplo:
Um produto com apenas 1 unidade em estoque
não deveria ser vendido para 2 pessoas ao mesmo tempo.
Nesses casos, o sistema precisa de controle transacional forte.
BASE
BASE é melhor quando o sistema precisa continuar disponível mesmo aceitando pequenos atrasos de consistência.
Exemplo:
Uma curtida pode demorar alguns segundos para aparecer para todos.
Outro exemplo:
Um feed pode carregar com alguns posts atrasados,
desde que o sistema continue respondendo.
Nesse tipo de cenário, ficar indisponível pode ser pior do que mostrar dados um pouco desatualizados.
Comparação direta
| Modelo | Prioridade | Onde costuma aparecer |
|---|---|---|
| ACID | Consistência forte | Bancos relacionais, pagamentos, ERPs, sistemas financeiros |
| BASE | Disponibilidade e escala | Sistemas distribuídos, redes sociais, feeds, NoSQL, caches |
| ACID | Segurança transacional | Operações críticas |
| BASE | Consistência eventual | Sistemas de alto volume e baixa tolerância a downtime |
E onde entra o CAP Theorem?
O CAP Theorem diz que, em um sistema distribuído, quando ocorre uma falha de comunicação entre partes do sistema, não é possível garantir perfeitamente as três propriedades ao mesmo tempo:
Consistency
Availability
Partition Tolerance
Em português:
Consistência
Disponibilidade
Tolerância a partição
Consistency
No CAP, consistência significa que todos os nós veem o mesmo dado ao mesmo tempo.
Se uma escrita acontece, qualquer leitura posterior deve retornar o valor mais atualizado.
Exemplo:
Se meu saldo foi atualizado, qualquer servidor que responder
deve mostrar o saldo correto.
Availability
Disponibilidade significa que toda requisição recebe uma resposta.
Mesmo que o dado não seja o mais atualizado, o sistema não simplesmente para de responder.
Exemplo:
Uma rede social continua carregando o feed
mesmo que alguns dados estejam atrasados.
Partition Tolerance
Tolerância a partição significa que o sistema continua funcionando mesmo quando existe falha de comunicação entre partes da rede.
Exemplo:
Dois datacenters perdem comunicação temporariamente,
mas o sistema precisa lidar com isso.
Em sistemas distribuídos reais, falhas de rede podem acontecer. Por isso, na prática, a tolerância a partição quase sempre precisa ser considerada.
Relação entre ACID, BASE e CAP
De forma simplificada:
ACID está mais próximo de consistência forte.
BASE está mais próximo de disponibilidade e consistência eventual.
No contexto do CAP:
- sistemas mais próximos de ACID tendem a priorizar consistência;
- sistemas mais próximos de BASE tendem a priorizar disponibilidade;
- ambos precisam lidar com falhas de rede em sistemas distribuídos.
Um sistema com comportamento mais AP tende a aceitar inconsistência temporária para continuar disponível.
Um sistema com comportamento mais CP tende a sacrificar disponibilidade em alguns cenários para preservar consistência.
Um ponto importante
Nem todo sistema é 100% ACID ou 100% BASE.
Na prática, sistemas modernos misturam estratégias.
Um e-commerce, por exemplo, pode usar:
- ACID no pagamento;
- ACID no controle crítico de estoque;
- BASE no feed de recomendações;
- BASE em notificações;
- BASE em métricas, logs e analytics.
Ou seja, a decisão não é necessariamente feita para o sistema inteiro.
Ela pode ser feita por parte do domínio.
Exemplo prático: e-commerce
Imagine um e-commerce.
Onde ACID faz sentido?
No pagamento:
O cliente não pode ser cobrado sem o pedido ser criado.
No estoque:
O sistema não pode vender 10 unidades se só existem 2.
Na criação de pedido:
O pedido precisa estar em um estado válido.
Onde BASE faz sentido?
Na notificação:
O e-mail de confirmação pode atrasar alguns segundos.
Nas recomendações:
Produtos recomendados podem estar levemente desatualizados.
No dashboard analítico:
O número de vendas pode levar alguns segundos ou minutos para atualizar.
Perceba que o mesmo produto pode usar ACID e BASE em lugares diferentes.
Resumo final
ACID e BASE representam escolhas diferentes de arquitetura.
ACID prioriza segurança transacional, integridade e consistência forte.
BASE prioriza disponibilidade, escalabilidade e tolerância a falhas, aceitando inconsistência temporária.
A grande questão em System Design é entender qual tipo de garantia cada parte do sistema precisa.
Não faz sentido tratar uma curtida em rede social com a mesma rigidez de uma transferência bancária.
Também não faz sentido tratar pagamento como se fosse um contador de visualizações.
No fim, a pergunta principal é:
Esse dado precisa estar correto agora
ou pode ficar consistente daqui a pouco?
Essa resposta define muita coisa sobre banco de dados, filas, cache, replicação, arquitetura e experiência do usuário.