O que são Transações ACID?

Uma transação ACID é um grupo de operações de banco de dados que faz commit como uma única unidade — atômica, consistente, isolada e durável. A ideia é anterior ao acrônimo: Jim Gray definiu as garantias em 1981, Härder e Reuter as batizaram de ACID em 1983, e quarenta anos depois ela segue sendo o contrato que permite mover dinheiro em software sem, de vez em quando, inventar ou destruir uma parte dele.

Principais pontos

Como transações ACID funcionam em SQL (exemplo de transferência bancária)

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';

-- Queda ou erro entre os dois updates? A engine faz rollback:
-- ROLLBACK;  →  as duas mudanças somem; dinheiro não pode evaporar

COMMIT;       -- ou as duas se tornam permanentes, de forma atômica e durável

O código de aplicação encontra as mesmas garantias em pacotes menores — operações atômicas de campo que encerram a corrida de read-modify-write, e lotes que fazem commit juntos:

// JavaScript / Node.js — Back4app JS SDK
// Atomicity where apps actually need it
counter.increment('sold', 1);        // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// All-or-nothing batch: both rows commit, or neither does
await Parse.Object.saveAll([debitEntry, creditEntry], { transaction: true });

// Flutter / Dart — Back4app Flutter SDK
// Atomicity where apps actually need it
counter.setIncrement('sold', 1);     // atomic single-field update — no
await counter.save();                // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
await ParseObject.saveAll([debitEntry, creditEntry]);

// iOS / Swift — Back4app Swift SDK
// Atomicity where apps actually need it
var updated = counter
updated.sold = (updated.sold ?? 0) + 1
// Prefer the atomic operation over read-modify-write:
let op = counter.operation.increment("sold", by: 1)
op.save { result in
  if case .success = result { print("atomic increment committed") }
}

// Android / Kotlin — Back4app Android SDK
// Atomicity where apps actually need it
counter.increment("sold")            // atomic single-field update — no
counter.saveInBackground()           // read-modify-write race possible

// Batches group writes; atomic counters remove the classic race
ParseObject.saveAllInBackground(listOf(debitEntry, creditEntry))

O ciclo de vida da transação: BEGIN, COMMIT e ROLLBACK

As quatro propriedades, cada uma pelo que quebra sem ela: atomicidade — sem ela, escritas parciais (a transferência debitada-mas-nunca-creditada). Consistência — sem ela, estados commitados que violam as suas próprias regras (estoque negativo, referências órfãs). Isolamento — sem ele, transações concorrentes leem o trabalho pela metade umas das outras. Durabilidade — sem ela, dados “commitados” que uma queda silenciosamente desfaz. Por baixo do capô, três mecanismos as entregam: logs de undo para o rollback, write-ahead logging para sobreviver a quedas e locks ou MVCC para a concorrência.

Níveis de isolamento vs. anomalias de leitura

A matriz que quase nenhum resultado de busca monta — qual nível impede qual anomalia:

Traduzindo: um dirty read enxerga trabalho não commitado; um non-repeatable read recebe respostas diferentes ao perguntar duas vezes; um phantom vê linhas surgirem no meio da transação. A maioria das engines modernas usa por padrão comportamento de snapshot baseado em MVCC — cada transação lê um snapshot consistente enquanto os escritores prosseguem — e é por isso que “leitores não bloqueiam escritores” virou a norma, não a exceção.

ACID vs. BASE — e o homônimo da consistência

Uma desambiguação carrega toda essa comparação: o C de ACID e o C de CAP são palavras diferentes vestindo a mesma letra. Consistência em ACID significa que cada transação preserva as regras que você declarou. Consistência em CAP significa que todos os nós concordam agora. Um banco de nó único é totalmente ACID sem que o CAP entre na sala; um sistema distribuído escolhe o seu trade-off de CAP e as suas garantias transacionais separadamente.

Quem garante o quê

Transações distribuídas merecem sua nota de rodapé honesta: o commit em duas fases (two-phase commit) compra atomicidade entre nós ao preço de latência e de um coordenador bloqueante, razão pela qual arquiteturas de microsserviços preferem cada vez mais as sagas — sequências de transações locais com rollbacks compensatórios, trocando consistência imediata por disponibilidade. Se um workflow genuinamente não tolera compensação, isso é evidência de que ele pertence a um único banco de dados, não a vários.

Casos de uso comuns

• Movimentação de dinheiro. Transferências, repasses, livros-razão — o caso canônico e ainda o mais claro.
• Estoque e reservas. Decrementar o estoque e confirmar o pedido juntos, ou assistir a dois clientes comprarem o último assento.
• Invariantes de múltiplas linhas. Pedido + itens, conta + registro de auditoria — registros que só nascem válidos juntos.
• Contadores do jeito certo. Incrementos atômicos — a menor dose útil de ACID — encerram a corrida de read-modify-write sem transações completas.
• O complemento de consistência eventual. Feeds, curtidas, analytics: explicitamente roteados para longe do custo transacional, de propósito.

Precisa ser ACID? Matriz de decisão

O ofício é rotear por escrita: o checkout usa transações, o contador de visualizações usa um incremento atômico, o feed tolera um segundo de deriva — uma aplicação, três faixas de preço para a consistência.

Limitações e trade-offs

• A coordenação é o centro de custo. Locks disputam, syncs de WAL batem no disco, retries de serializable abortam — a correção tem uma conta de throughput, e essa é a razão inteira de o BASE existir.
• Níveis de isolamento são um padrão traiçoeiro. A maioria das engines não usa serializable por padrão; conheça o seu nível, ou anomalias que você achava impossíveis são apenas improváveis.
• Transações longas são um mau sinal. Segurar locks durante o tempo de decisão do usuário ou chamadas de rede transforma garantias em contenção; mantenha transações curtas e decididas.
• ACID distribuído é caro por natureza. Rodadas de consenso a cada commit — pague onde as invariantes exigem, não em todo lugar por reflexo.
• ACID não valida as suas regras por você. A consistência preserva constraints declaradas; regras de negócio nunca codificadas são fielmente não aplicadas.

Transações ACID no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Seu kit transacional corresponde a como os apps realmente consomem ACID: toda escrita de objeto único é atômica na engine de documentos subjacente, incrementos atômicos e operações de array encerram as clássicas corridas de contador (as abas de código acima), saves em lote agrupam escritas, e invariantes de múltiplas etapas pertencem ao Cloud Code — validadas e executadas no servidor, onde um trigger beforeSave pode recusar qualquer escrita que quebraria as regras. A matriz de decisão vem de fábrica: atomicidade barata por padrão, coordenação completa onde você pedir.