O Que É Atomicidade Em Banco De Dados

Transações, logs e o problema que ninguém resolve direito

A maior parte dos desenvolvedores aprende sobre atomicidade na faculdade com exemplos bonitinhos de transferência bancária. Depois entra numa empresa real e percebe que o conceito é muito mais cinzento do que parece. Atomicidade significa, de forma simplificada, que uma transação inteira acontece ou nada dela acontece. Se qualquer parte falhar, tudo é desfeito. Isso soa simples até você ter um sistema de produção rodando às três da manhã. O termo vem das propriedades ACID, onde o A é justamente esse princípio de que transações são indivisíveis. Numa operação atômica, você nunca vai ter metade do trabalho feito. Se você move dinheiro da conta A para a conta B, o débito em A e o crédito em B precisam ser ambos confirmados ou ambos revertidos. Não existe cenário aceitável onde A perde dinheiro e B não recebe. No mundo real, isso funciona graças ao log de transações. O banco escribe primeiro as intenções no log, depois aplica as mudanças. Se algo der errado, ele lê o log e desfaz. O processo costuma levar entre 2 e 5 milissegundos por operação simples em bancos como PostgreSQL ou MySQL com InnoDB. Depende muito da configuração de flush do disco e se você está usando WAL (Write-Ahead Logging) ou não.

Eu trabalhava numa migration de dados há alguns anos quando descobri que a atomicidade do PostgreSQL não protege você de problemas de lógica aplicada em nível de aplicação. Eu escrevi um script que processava 2 milhões de registros em batches de 500. Cada batch era uma transação atômica, certo. O problema era que o servidor tinha um cycle de checkpoint de 5 minutos configurado, e durante a migração eu estava fazendo atualizações pesadas em tabelas anexas que não estavam dentro das minhas transações. No final, tinha 47 mil registros órfãos que pareciam consistentes dentro da sua transação individual, mas quebravam a integridade referencial quando você via o panorama todo. A solução foi aumentar a frequência de checkpoints e adicionar um constraints NOT NULL numa coluna que eu achava dispensável, forçando o banco a rejeitar rows inválidas no ato da inserção em vez de descobrir o problema dias depois. Um ponto que pouca gente menciona: atomicidade não quer dizer velocidade. Transações maiores são mais caras porque precisam manter locks por mais tempo e gerar mais log. Num projeto anterior, dividimos uma transação única de 15 segundos em 12 transações menores de aproximadamente 1 segundo cada, e o throughput do sistema dobrou. O trade-off é que agora tínhamos maior exposição a deadlocks, mas pelo menos cada operação individual falhava de forma isolada e recuperável. Também é importante saber que atomicidade tem custo. Quanto mais granularidade você usa, mais overhead de logging e lock management o banco precisa processar. Em sistemas com carga massiva de escritas concorrentes, o gargalo muitas vezes não é a CPU ou disco, mas sim o WAL writer e o gerenciador de locks. Eu vi um cenário onde uma fila de mensagens processava transações em lote com commit automático desligado, e o log de transações cresceu para 80 gigabytes antes do primeiro commit ser disparado. A recuperação após uma queda exigiu quase 40 minutos apenas para replay do WAL.

A limitação mais honesta que existe é que atomicidade em banco de dados só cobre o que acontece dentro do próprio banco. Se você precisa que uma operação no banco e uma ação num serviço externo sejam atômicas juntos, o banco sozinho não resolve. Você precisa de um padrão como two-phase commit ou, mais realisticamente, aceitar consistência eventual com compensações via saga pattern. Two-phase commit funciona na teoria mas introduz bloqueio distribuído que mata performance e é ponto único de falha. Na prática, 90% dos times acabam implementando compensação manual com retry e log de eventos. Se você está começando, o conselho mais útil é simples: entenda qual é o escopo da sua transação antes de abrir qualquer transaction block. Defina claramente onde ela começa e onde termina, e evite colocar operações de rede ou chamadas a APIs externas dentro dela. Transações longas que aguardam resposta de serviços terceiros são a principal causa de problemas de atomicidade em sistemas reais, porque o lock fica retido indefinidamente e outros processos acabam bloqueados atrás dele.