ACID: A Espinha Dorsal da Confiabilidade nos Bancos de Dados

Entendendo a importância de ACID em Bancos de Dados

Banco de Dados x ACID

Você já parou para pensar o que realmente garante que seus dados não desapareçam ou se corrompam mesmo quando tudo dá errado?

Essa confiança se deve às propriedades ACID, um conjunto de garantias implementadas por sistemas de banco de dados relacionais e alguns NoSQL modernos para manter a integridade dos dados em transações.

O que é ACID?

ACID representa:

• Atomicidade

• Consistência

• Isolamento

• Durabilidade

  
  

Vamos mergulhar em cada uma delas com exemplos reais, bancos que suportam, e como o ACID age nos bastidores.

1. Atomicidade (Atomicity)

Tudo ou nada.

Se qualquer parte da transação falhar, nenhuma das operações é aplicada. O banco garante rollback automático se necessário.

Como isso funciona internamente?

• O banco cria um log transacional (como o WAL – Write Ahead Log no PostgreSQL).

• Todas as operações são registradas antes de serem aplicadas.

• Se houver falha antes do COMMIT, o banco usa o log para reverter tudo.

  
  

Bancos que garantem atomicidade:

• PostgreSQL

• MySQL (InnoDB)

• Oracle

• Microsoft SQL Server

• SQLite (modo WAL)

Exemplo prático:

BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
UPDATE contas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;

Se o sistema falhar após o primeiro UPDATE, o banco automaticamente reverte o débito da conta 1.

2. Consistência (Consistency)

A transação leva o banco de um estado válido a outro estado válido.

Regras de integridade, constraints e relacionamentos devem sempre ser respeitados.

O que o banco garante?

• Constraints (NOT NULL, CHECK, UNIQUE, FOREIGN KEY)

• Tipagem forte

• Integridade referencial

  
  

Bancos que implementam essa consistência:

• PostgreSQL e Oracle são referências em validações consistentes.

• MySQL com InnoDB também suporta, mas o modo MyISAM, por exemplo, não garante consistência transacional.

• MongoDB possui consistência de documentos (mas não entre coleções por padrão).

Exemplo prático:

-- Esta tabela não permite saldo negativo

CREATE TABLE contas (
id SERIAL PRIMARY KEY,
saldo NUMERIC CHECK (saldo >= 0)
);

BEGIN;
UPDATE contas SET saldo = saldo - 200 WHERE id = 1; -- saldo era 150
COMMIT;

Resultado: a transação falha, e o banco mantém o estado anterior — sem corrupção de dados.

 3. Isolamento (Isolation)

Transações simultâneas não devem afetar o resultado final da outra.

É aqui que entra a complexidade da concorrência!

Níveis de isolamento:

Bancos com controle robusto de isolamento:

• PostgreSQL: usa MVCC (Multi-Version Concurrency Control). Leitores nunca bloqueiam escritores e vice-versa.

• Oracle: também usa MVCC.

• SQL Server: usa locks, mas possui Snapshot Isolation semelhante ao MVCC.

• MySQL InnoDB: suporta todos os níveis, com MVCC parcial.

 Exemplo prático:

-- Sessão 1
BEGIN;
SELECT saldo FROM contas WHERE id = 1; -- retorna 500

-- Sessão 2
BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;

-- Sessão 1 (ainda dentro da mesma transação)
SELECT saldo FROM contas WHERE id = 1; -- retorna 500 em REPEATABLE READ

Mesmo após o commit da sessão 2, a sessão 1 vê os dados antigos, pois trabalha com uma versão estável dos dados.

Quer aprender mais sobre SQL? Baixe nosso E-Book Gratuito clicando aqui!

4. Durabilidade (Durability)

Se o banco disse que salvou, ele salvou. Mesmo se cair a energia.

Como isso é garantido?

• Gravação física em disco antes do COMMIT

• Uso de WAL, journaling ou arquivos de undo/redo

• Operações fsync() no SO

  
  

Bancos com durabilidade forte:

• PostgreSQL (WAL + fsync)

• Oracle (redo log + archive log)

• MySQL InnoDB (doublewrite buffer)

• MongoDB com journaling habilitado

• Cassandra com commitlog (embora não seja full-ACID, há durabilidade por partição)

  
  

Exemplo prático:

Você executa:

BEGIN;
INSERT INTO pedidos (cliente, total) VALUES ('João', 150.00);
COMMIT;

O servidor reinicia logo depois.

Se o banco seguiu o protocolo corretamente, no momento do COMMIT, os dados já foram sincronizados no disco. Ao reiniciar, o banco faz o recovery com base nos logs e os dados estão lá.

Por que você deve se importar com ACID?

• Garante que transações financeiras não sejam incompletas.

• Evita corrupção de dados em sistemas de saúde, educação, segurança.

• Permite construção de sistemas distribuídos com confiança, especialmente quando integrado com estratégias como 2PC (Two-Phase Commit) ou SAGA patterns.

Comparativo: Bancos Relacionais e NoSQL quanto ao ACID

Comparações de Bancos de Dados que suportam ACID

Conclusão

ACID é o que separa bancos de dados confiáveis de armazenadores de dados frágeis.

Mesmo bancos NoSQL modernos estão buscando formas de oferecer essas garantias. Se você está construindo qualquer aplicação que envolva consistência crítica, entender e aplicar ACID é obrigatório.

---

Quer Aprender Mais? Inscreva-se na nossa Newsletter semanal!

Não perca nossas dicas exclusivas de Tech e Data!

Inscreva-se Agora na Newsletter da Coffee & Tips

Receba semanalmente:

• Tutoriais práticos e diretos sobre Engenharia de Software e Dados

• Insights de tecnologia e notícias da semana