Atomicidade em bancos de dados: A espinha dorsal de transações confiáveis

A atomicidade é um conceito fundamental nos sistemas de banco de dados. Isso significa que uma transação deve ser totalmente bem-sucedida ou não ser executada. Se alguma coisa falhar no meio do caminho, tudo será revertido como se nunca tivesse acontecido.

Por que isso é tão importante, você pergunta? Imagine transferir dinheiro de uma conta bancária para outra. Você pressiona "Enviar", o aplicativo carrega por um segundo e, em seguida, algo dá errado. O dinheiro desaparece de sua conta, mas nunca chega à outra. Agora você simplesmente... desapareceu. Esse cenário é exatamente o que a atomicidade foi projetada para evitar.

Talvez você já tenha ouvido falar de ACID. É um conjunto de quatro propriedades principais que os bancos de dados usam para garantir que as coisas não desmoronem. A atomicidade é a primeira da lista, e por um bom motivo: sem ela, o restante (consistência, isolamento e durabilidade) não tem muita importância.

Neste artigo, exploraremos o que significa atomicidade, como ela funciona e por que é tão importante em sistemas cotidianos, como bancos e comércio eletrônico. Também veremos como diferentes bancos de dados o implementam e como você pode projetar sistemas atômicos capazes de lidar bem com as coisas quando elas inevitavelmente dão errado.

O que é atomicidade?

Atomicidade significa que uma transação em um banco de dados é indivisível. Ou ele é executado até o fim, com cada etapa ocorrendo de acordo com o planejado, ou não é executado. Não há meio termo. Sem atualizações pela metade, sem dados parciais salvos, sem um limbo estranho em que algumas coisas foram bem-sucedidas e outras não.

Atomicidade em DBMS. Fonte: Arpit Bhayani

Se uma parte da transação falhar, toda ela será revertida como se nada tivesse acontecido. É isso que torna a atomicidade uma proteção tão poderosa. Sem ele, você correria o risco constante de deixar seus dados em um estado corrompido ou inconsistente, especialmente em sistemas em que várias coisas precisam acontecer em sequência.

Vamos analisar alguns cenários do mundo real em que a atomicidade faz (ou quebra) o sistema:

Exemplo 1: Transferência bancária

Digamos que você esteja transferindo US$ 100 de sua conta corrente para sua conta poupança.

A transação tem duas partes:

1. Deduzir US$ 100 de conta corrente
2. Adicione US$ 100 à poupança

Sem atomicidade, é possível que a etapa um seja concluída e a etapa dois falhe, talvez devido a uma falha na rede ou no servidor. Parabéns, seu dinheiro acabou de desaparecer no vazio. A atomicidade garante que ambas as etapas sejam bem-sucedidas, ou nenhuma delas. Se algo der errado, os US$ 100 permanecerão exatamente onde estavam no início.

Exemplo 2: Inventário e processamento de pedidos

Você está comprando o último disco de vinil de edição limitada on-line. O sistema precisa:

1. Reduzir o estoque em um
2. Confirme seu pedido

Sem atomicidade, ele pode reduzir o estoque, mas falhará antes que o pedido seja confirmado. Agora a loja acha que o produto está fora de estoque, mas ninguém recebe o registro. 

A quantidade de vezes que isso acontece comigo ao comprar algo on-line é surpreendente. Normalmente, fecho a guia e desejo boa sorte aos engenheiros, mas provavelmente não tentarei comprar nesse site no futuro. Quem sabe como eles lidarão com meus dados pessoais se não puderem garantir que sua principal funcionalidade de compras seja confiável?

Exemplo 3: Sistema de reserva de voos

A reserva de um voo geralmente é mais do que apenas selecionar um assento. O sistema precisa:

1. Atribuir o assento
2. Atualizar a disponibilidade de assentos
3. Carregue seu cartão

Se a etapa 2 falhar e a etapa 3 for concluída, você pagou por um assento que não existe. Não é o ideal.

Exemplo 4: Sincronização do banco de dados e do índice de pesquisa

Digamos que seu aplicativo atualize a descrição de um produto no banco de dados principal. Ao mesmo tempo, ele deve atualizar o índice de pesquisa para que os usuários possam encontrar o produto com a nova descrição.

Se a atualização do banco de dados for bem-sucedida, mas a atualização do índice falhar, os usuários verão resultados desatualizados ou não conseguirão encontrar o produto.

Por que a atomicidade é importante

Então, por que a atomicidade é tão importante? 

Há muitos motivos pelos quais uma transação pode ser interrompida. Pode haver uma queda de energia, uma falha no servidor ou um tempo limite da rede no meio do caminho. Se a atomicidade não for imposta, essa transação poderá ser concluída apenas parcialmente. Agora, seu banco de dados ficou em um estado estranho: algumas alterações foram feitas, outras não, e você não tem uma maneira fácil de desfazer a bagunça.

É aqui que os bugs de dados se tornam realmente sorrateiros. Os usuários podem não perceber nada de errado no início, mas, com o tempo, as coisas deixam de fazer sentido. Suas análises parecem estranhas, os pedidos desaparecem, as contas não são saldadas ou os tíquetes de suporte aumentam porque as pessoas não conseguem encontrar o que acabaram de salvar.

A atomicidade evita tudo isso, pois garante que você tenha uma boa visão:

• Uma transação pode ocorrer completamente ou não ocorrer de forma alguma
• O sistema pode se recuperar de forma limpa, mesmo que algo falhe no meio do caminho
• Seus dados permanecem consistentes, mesmo durante falhas no sistema ou acesso simultâneo

Ela também está intimamente ligada às outras propriedades do ACID. Sem atomicidade, a consistência vai por água abaixo, pois você não pode aplicar regras se metade dos dados estiver faltando, e o isolamento é interrompido, pois outros usuários podem ver dados parciais de uma transação incompleta.

Isso é especialmente importante se você estiver lidando com:

• Transações em várias etapas, em que uma ação depende de outra.
• Atualizações de várias linhas ou tabelas, em que os dados relacionados precisam ser mantidos em sincronia.
• Sistemas distribuídos, em que partes da transação ocorrem em diferentes máquinas ou bancos de dados.

Como a atomicidade funciona na prática

Por trás da simplicidade do "tudo ou nada" está um sistema surpreendentemente intrincado. Quando um banco de dados executa uma transação, ele está ativamente rastreando, preparando e protegendo cada etapa.

Aqui está uma visão de alto nível do que está acontecendo:

O ciclo de vida da transação

1. Iniciar a transação: O sistema marca o início de uma transação, isolando as próximas alterações do restante do banco de dados.
2. Executar a operação: Isso inclui todas as suas inserções, atualizações, exclusões ou qualquer outra mágica SQL que você esteja fazendo.
3. Confirmação ou reversão: Se todas as operações forem bem-sucedidas, a transação será confirmada e as alterações se tornarão permanentes. Se houver alguma falha, toda a transação será revertida.

Registro em log e diário

Para garantir a atomicidade, os bancos de dados gravam logs do que vai acontecer antes de realmente acontecer. Esses registros são armazenados separadamente e funcionam como um plano de backup.

Se o sistema travar no meio da transação, ele poderá consultar o registro e reverter todas as alterações incompletas, reaplicar as concluídas com segurança e restaurar o banco de dados para um estado limpo e consistente.

Essa abordagem às vezes é chamada de Write-Ahead Logging (WAL) ou registro em diário, e é uma peça fundamental da recuperação de falhas.

Reversões e recuperação

Quando uma transação falha, o banco de dados não simplesmente desiste, ele desfaz cuidadosamente as alterações. As linhas modificadas são restauradas ao seu estado original, todos os bloqueios mantidos pela transação são liberados e os registros são usados para reverter atualizações parciais.

Agora, no caso de uma falha, as rotinas de recuperação entram em ação no momento da reinicialização. Eles reproduzem logs, resolvem transações inacabadas e garantem que o banco de dados seja retomado exatamente de onde parou, sem estados intermediários estranhos.

Desempenho vs. atomicidade

Não é de se surpreender que tudo isso tenha um custo. A atomicidade é apresentada:

• Bloqueio: Para evitar que outras pessoas modifiquem os mesmos dados no meio da transação
• Sobrecarga: De mecanismos de registro e reversão
• Deadlocks: Quando várias transações esperam umas pelas outras para liberar recursos

É por isso que você precisa projetar grandes transações com cuidado. Se você fizer muito de uma só vez, poderá tornar todo o sistema mais lento ou ter problemas de concorrência.

Atomicidade em sistemas de banco de dados populares

A atomicidade é um conceito central em todos os principais bancos de dados, mas a forma como é implementada pode variar um pouco, dependendo do mecanismo de armazenamento subjacente e da filosofia de design. Vamos dar uma olhada em como o PostgreSQL e o MySQL (InnoDB) garantem que as transações funcionem corretamente.

PostgreSQL

Antes que qualquer dado seja gravado permanentemente, o PostgreSQL cria um registro de gravação antecipada (WAL), o registro de cada alteração pretendida sobre a qual falamos anteriormente. Esse registro é armazenado com segurança e usado como um plano de recuperação, caso algo dê errado durante a transação.

Quando uma transação é confirmada, o PostgreSQL verifica o WAL, confirma que todas as alterações estão completas e são válidas e, em seguida, finaliza as atualizações. Se algo falhar no meio do caminho, o banco de dados usará esse registro para reverter o trabalho incompleto.

O que é ótimo é que tudo isso acontece automaticamente nos bastidores. Do ponto de vista do desenvolvedor, é perfeito: você escreve uma transação e o PostgreSQL garante a atomicidade sem que você precise gerenciar qualquer complexidade.

Nenhuma alteração fica visível para outros usuários até que a transação seja totalmente confirmada. Isso mantém as coisas consistentes e evita qualquer estranheza "meio salva" em ambientes multiusuário.

PostgreSQL WAL. Fonte: AlgoMaster

Se você quiser colocar a mão na massa e criar seus próprios bancos de dados para testar transações, dê uma olhada no nosso curso PostgreSQL.

MySQL (InnoDB)

O mecanismo de armazenamento InnoDB do MySQL também oferece suporte a transações atômicas, e sua abordagem foi criada para garantir confiabilidade e desempenho.

Como o PostgreSQL, o InnoDB usa um log de transações para manter o controle das alterações antes de confirmá-las. Se algo falhar, o registro será usado para reverter tudo para o estado anterior à transação. Isso garante que nenhuma atualização parcial passe despercebida.

Uma coisa que o InnoDB faz muito bem é agrupar as gravações. Isso ajuda a reduzir a E/S do disco e melhora o desempenho, ao mesmo tempo em que protege a atomicidade. Ele também usa logs de desfazer para reverter as alterações durante uma reversão e logs de refazer para recuperação de falhas.

Assim como no PostgreSQL, você pode contar com o banco de dados para lidar com esses mecanismos para você. Você não precisa escrever nenhum código de reversão personalizado.

Principais conclusões para engenheiros e arquitetos de dados

Há algumas coisas que você deve ter em mente ao trabalhar com transações atômicas em seus próprios projetos. A ideia geral é tratar a atomicidade como um padrão, não como um luxo. Se você estiver criando sistemas que modificam dados em mais de um lugar ao mesmo tempo (o que é basicamente o caso de todos eles), projetar com a atomicidade em mente economizará tempo, sanidade mental e, possivelmente, uma notificação de incidente às 3h da manhã. 

Escolha o banco de dados certo para o trabalho

Nem todos os bancos de dados lidam com a atomicidade da mesma maneira, e nem todos os mecanismos de armazenamento são criados da mesma forma. Se a atomicidade for essencial para o seu caso de uso (por exemplo, finanças, logística, gerenciamento do estado do usuário), certifique-se de que o banco de dados seja compatível com transações ACID completas. Isso é especialmente relevante se você estiver usando o MySQL, onde a escolha do mecanismo de armazenamento é importante.

Design para falhas

Suponha que as coisas darão errado, porque elas darão. Envolva operações de várias etapas em transações e trate os erros adequadamente. Seja explícito com suas declarações BEGIN,COMMIT e ROLLBACK ou use estruturas que as manipulem com segurança.

A maioria dos ORMs e camadas de acesso a dados modernos oferece suporte integrado a transações. Por exemplo:

• No Node.js, bibliotecas como Prisma e TypeORM permitem que você envolva a lógica em uma chamada transaction() que lida com o commit/rollback nos bastidores.

• Em Python, o SQLAlchemy oferece gerenciadores de contexto (com session.begin():) que garantem confirmações e reversões seguras.

• Em Java, estruturas como o Spring permitem que você anote métodos com @Transactionalpara que o banco de dados trate tudo atomicamente, mesmo em várias chamadas de função.

Essas ferramentas facilitam muito a criação segura por padrão. Eles reduzem o risco de você esquecer uma reversão ou gerenciar mal a lógica de confirmação, especialmente quando o aplicativo se torna mais complexo.

Equilibre o desempenho com a confiabilidade

A atomicidade vem com alguma sobrecarga, especialmente em transações grandes. Sempre que possível, divida as operações em massa, evite bloquear tabelas inteiras e mantenha as transações curtas e concentradas. As transações de longa duração aumentam o risco de contenção, deadlocks e usuários insatisfeitos.

Compreender as dependências e o isolamento

Como vimos anteriormente, a atomicidade não existe em um vácuo, mas em conjunto com a consistência e o isolamento. Certifique-se de que as alterações relacionadas ocorram juntas e considere como as transações simultâneas podem interagir. Use níveis de isolamento adequados à sua carga de trabalho sem complicar demais as coisas.

Propriedades ACID em DBMS. Fonte: DataCamp

Teste com cenários de falha realistas

Não teste apenas seus caminhos felizes. Simule o que acontece quando seu aplicativo trava no meio de uma transação ou quando uma consulta atinge o tempo limite. Você pode usar pontos de falha ou simular falhas no banco de dados para ver como o sistema se comporta sob pressão.

Conclusão

Se você estiver criando sistemas em que várias coisas precisam acontecer juntas, a atomicidade não é opcional, é essencial. Quer você esteja movimentando dinheiro entre contas, atualizando o inventário ou sincronizando sistemas, a atomicidade garante que seus dados não acabem em um estado quebrado ou incompleto.

Se você quiser se aprofundar mais, por que não fazer nosso curso de Design de banco de dados? Você aprenderá a projetar bancos de dados em SQL para processar, armazenar e organizar dados de forma mais eficiente.

E se você estiver interessado em artigos e tutoriais mais práticos sobre design de bancos de dados, dê uma olhada em nossa série sobre normalização de bancos de dados:

• Normalização em SQL (1NF - 5NF): Um guia para iniciantes tutorial
• O que é a Primeira Forma Normal (1NF)? tutorial
• O que é a Segunda Forma Normal (2NF)? tutorial
• O que é a Terceira Forma Normal (3NF)? Tutorial
• O que é dependência transitiva? Tutorial