o que e acid

Author: ewertoncodes

_posts/2026-05-06-o-que-acid.md

@@ -0,0 +1,190 @@
+---
+layout: post
+title: "O que é ACID?"
+date: 2026-05-04 11:40:00 -0300
+categories: database
+tags: [database, sql]
+---
+
+# O que é ACID?
+
+Imagine um sistema de compra de ingressos, onde você precisa comprar um ingresso 
+para um show. Você clica em "Comprar", o sistema verifica se tem ingressos 
+disponíveis, reserva um para você, debita o valor do seu cartão de crédito e gera 
+o ingresso. Agora imagine que, no meio desse processo, o sistema falha. O que 
+acontece com o seu ingresso? E com o seu dinheiro?
+
+Para garantir que isso não aconteça, os bancos de dados relacionais implementam o 
+ACID, que é um conjunto de propriedades que garantem que as transações sejam 
+processadas de forma confiável. Cada propriedade resolve um problema diferente: 
+a Atomicidade garante que nada fique pela metade, a Consistência garante que o 
+banco nunca fique em um estado inválido, o Isolamento garante que compradores 
+simultâneos não se atrapalhem, e a Durabilidade garante que o ingresso comprado 
+não desapareça depois.
+
+## Atomicidade
+
+Na **Atomicidade** uma transação ou é executada por completo ou não é executada. 
+Não existe meio termo. No nosso exemplo, se o sistema falhar no meio do processo, 
+o dinheiro não será debitado do cartão e o ingresso não será gerado. A transação 
+será revertida por completo.
+
+O exemplo clássico é uma transferência entre duas contas, onde o dinheiro sai de 
+uma conta e entra na outra.
+
+{% highlight ruby %}
+ActiveRecord::Base.transaction do
+  david.withdrawal(100)
+  mary.deposit(100)
+end
+{% endhighlight %}
+
+Esse exemplo só levará dinheiro de David e dará para Mary se nem withdrawal nem 
+deposit levantarem uma exceção. As exceções forçarão um ROLLBACK que retorna o 
+banco de dados ao estado anterior ao início da transação.
+
+Mas, se nem withdrawal nem deposit levantarem uma exceção, então a transação será 
+concluída com sucesso. Ou seja, o dinheiro sairá da conta de David e entrará na 
+conta de Mary.
+
+## Consistência
+
+A **Consistência** garante que a transação leve o banco de dados de um estado 
+válido para outro estado válido. Ou seja, se uma transação não for concluída com 
+sucesso, o banco de dados não será alterado.
+
+No exemplo dos ingressos, isso significa que não é possível comprar um ingresso 
+com uma quantidade negativa ou com dados obrigatórios em branco. O banco rejeita 
+qualquer operação que violaria suas regras.
+
+{% highlight ruby %}
+ticket = Ticket.last
+ticket.update(id:nil)
+# =>
+# PG::NotNullViolation: ERROR:  null value in column "id" of relation "tickets" 
+# violates not-null constraint (ActiveRecord::NotNullViolation)
+# DETAIL:  Failing row contains (null, 2026-04-29 06:01:26.693314, 173335, 
+# 2026-05-06 19:20:28.89082, 90, 5).
+{% endhighlight %}
+
+O banco recusa a operação e permanece exatamente como estava — nenhum estado 
+inválido é persistido.
+
+## Isolamento
+
+No **Isolamento** é garantido que transações não interfiram umas nas outras. 
+Vamos voltar ao exemplo dos ingressos. Maria e João estão comprando o último 
+ingresso disponível.
+Se o isolamento não estiver ativo, João pode ver que há um ingresso disponível e 
+iniciar a compra também. Nesse caso, ambos podem comprar o ingresso, o que não 
+deveria acontecer. Para evitar isso, o isolamento garante que as transações não 
+interfiram umas nas outras. A compra de Maria deve ser concluída antes que a de 
+João possa ser iniciada.
+
+{% highlight ruby %}
+# app/services/ticket_purchase_service.rb
+class TicketPurchaseService
+  class TicketUnavailableError < StandardError; end
+
+  def self.purchase(ticket_id:, buyer_name:)
+    ActiveRecord::Base.transaction(isolation: :serializable) do
+      # WITH LOCK garante que apenas uma transação por vez acesse esse registro
+      ticket = Ticket.lock("FOR UPDATE").find(ticket_id)
+
+      raise TicketUnavailableError, "Ingresso não disponível!" unless ticket.available?
+
+      # Simula o tempo de processamento (onde a corrida aconteceria sem isolamento)
+      sleep(0.1)
+
+      ticket.update!(available: false, owner_name: buyer_name)
+
+      puts "[#{buyer_name}] ✅ Compra realizada com sucesso!"
+      ticket
+    end
+  rescue TicketUnavailableError => e
+    puts "[#{buyer_name}] ❌ #{e.message}"
+    nil
+  end
+end
+{% endhighlight %}
+
+Demonstração do problema SEM isolamento (race condition)
+
+{% highlight ruby %}
+def demo_sem_isolamento(ticket_id)
+  puts "\n=== SEM ISOLAMENTO ==="
+
+  # Maria e João leem ao mesmo tempo que o ingresso está disponível
+  thread_maria = Thread.new do
+    ticket = Ticket.find(ticket_id)
+    sleep(0.05) # simula processamento
+    if ticket.available?
+      ticket.update!(available: false, owner_name: "Maria")
+      puts "[Maria] ✅ Compra realizada! (mas João também pode comprar)"
+    end
+  end
+
+  thread_joao = Thread.new do
+    ticket = Ticket.find(ticket_id)
+    sleep(0.05) # lê o mesmo estado "disponível"
+    if ticket.available?
+      ticket.update!(available: false, owner_name: "João")
+      puts "[João] ✅ Compra realizada! (ingresso duplicado 💥)"
+    end
+  end
+
+  [thread_maria, thread_joao].each(&:join)
+end
+{% endhighlight %}
+
+Com isolamento via FOR UPDATE + transaction serializable
+
+{% highlight ruby %}
+def demo_com_isolamento(ticket_id)
+  puts "\n=== COM ISOLAMENTO ==="
+
+  thread_maria = Thread.new do
+    TicketPurchaseService.purchase(ticket_id: ticket_id, buyer_name: "Maria")
+  end
+
+  thread_joao = Thread.new do
+    TicketPurchaseService.purchase(ticket_id: ticket_id, buyer_name: "João")
+  end
+
+  [thread_maria, thread_joao].each(&:join)
+end
+
+# Resultado esperado com isolamento:
+# [Maria] ✅ Compra realizada com sucesso!
+# [João]  ❌ Ingresso não disponível!
+{% endhighlight %}
+
+## Durabilidade
+
+Na **Durabilidade** é garantido que uma vez que uma transação seja concluída com 
+sucesso, ela não será desfeita, mesmo em caso de falha do sistema. No exemplo dos 
+ingressos, uma vez que Maria compra o ingresso, ele não pode ser vendido novamente.
+
+Isso significa que mesmo que o servidor reinicie logo após a compra, o registro 
+da transação de Maria já está gravado permanentemente no banco.
+
+{% highlight ruby %}
+ActiveRecord::Base.transaction do
+  ticket.update!(available: false, owner_name: "Maria")
+end
+
+# Mesmo que o servidor caia aqui, a compra de Maria está salva.
+ticket.reload
+puts ticket.owner_name  # => "Maria"
+puts ticket.available   # => false
+{% endhighlight %}
+
+## Conclusão
+
+Voltando ao cenário inicial: você clica em "Comprar", o sistema processa tudo — 
+e no meio do caminho algo falha. Graças ao ACID, você não perde dinheiro sem 
+receber o ingresso (Atomicidade), o banco não aceita dados inválidos no processo 
+(Consistência), Maria e João não compram o mesmo ingresso ao mesmo tempo 
+(Isolamento), e uma vez confirmada a compra, ela não some (Durabilidade). As 
+quatro propriedades juntas são o que torna um banco de dados confiável para 
+transações do mundo real.