DEV Community: André Moreira

Dominando Transações de Banco de Dados: Do Conceito à Prática com Laravel

André Moreira — Tue, 21 Jul 2026 17:50:11 +0000

Dominando Transações de Banco de Dados: Do Conceito à Prática com Laravel

Quantas vezes você se perguntou: "E se der erro na metade da operação?" Transações de banco de dados são o escudo invisível que protege a integridade dos seus dados. Vamos entender isso a fundo.

O Problema Real

Imagine um sistema de transferência bancária:

Débito da conta A: ✓
Erro de rede
Crédito na conta B: ✗

Resultado? Dinheiro desaparece. Transações resolvem isso garantindo "tudo ou nada".

Conceitos Fundamentais: ACID

Antes de codar, precisamos entender os pilares:

Atomicidade (A)

A transação é uma unidade indivisível. Ou todas as operações completam, ou nenhuma. Sem meio termo.

Consistência (C)

O banco sempre sai de um estado válido para outro válido. Regras de negócio são respeitadas.

Isolamento (I)

Transações simultâneas não interferem umas nas outras. Cada uma vê um snapshot consistente dos dados.

Durabilidade (D)

Uma vez confirmada, os dados persistem. Mesmo com falhas de hardware.

Níveis de Isolamento: O Trade-off

Aqui está o segredo que muitos desenvolvedores não dominam completamente:

-- De menor para maior isolamento (maior custo de performance)

READ UNCOMMITTED    -- Dirty reads possíveis ⚠️
READ COMMITTED      -- Padrão do PostgreSQL (equilibrado)
REPEATABLE READ     -- Padrão do MySQL InnoDB
SERIALIZABLE        -- Total segurança, performance limitada

Qual usar? Depende do seu caso de uso:

E-commerce: READ COMMITTED geralmente basta
Relatórios financeiros: SERIALIZABLE
Blog: READ UNCOMMITTED é aceitável

Na Prática com Laravel

1. Transação Básica

use Illuminate\Support\Facades\DB;

DB::transaction(function () {
    $user = User::create([
        'name' => 'João',
        'email' => 'joao@example.com'
    ]);

    Account::create([
        'user_id' => $user->id,
        'balance' => 1000
    ]);
    // Se algo der erro aqui, ambas operações são revertidas
});

2. Controle Manual com Savepoints

DB::beginTransaction();

try {
    // Primeira operação
    $transfer = Transfer::create([
        'from_account' => 1,
        'to_account' => 2,
        'amount' => 100
    ]);

    DB::savepoint(1); // Ponto de restauração

    // Operação arriscada
    $notification = $this->sendNotification($transfer);

    DB::commit();
} catch (Exception $e) {
    DB::rollbackToSavepoint(1); // Volta ao ponto, mas mantém a transação

    // Agora você pode decidir: fazer retry, log, etc
    Log::error('Notification failed', ['transfer_id' => $transfer->id]);

    DB::commit(); // Commita a transferência, ignora notificação
}

3. Definindo Nível de Isolamento

// PostgreSQL
DB::connection()->statement("SET TRANSACTION ISOLATION LEVEL SERIALIZABLE");

DB::transaction(function () {
    // suas operações
});

// MySQL
DB::beginTransaction();
DB::connection()->statement("SET TRANSACTION ISOLATION LEVEL REPEATABLE READ");

// suas operações

DB::commit();

4. Timeout de Transação

// Evite deadlocks com timeout
DB::connection()->statement("SET lock_wait_timeout = 5"); // MySQL: 5 segundos

DB::transaction(function () {
    // Se travar por mais de 5s, lança exception
    AccountLock::create(['account_id' => 1]); // Simula lock
}, maxAttempts: 3); // Tenta 3 vezes antes de desistir

Armadilhas Comuns (e como evitá-las)

❌ Armadilha 1: Transações Muito Longas

// NÃO FAÇA ISSO
DB::transaction(function () {
    // Aqui você está lockando recursos
    $data = fetchFromExternalAPI(); // Pode demorar 30s!

    // Enquanto isso, outras transações ficam esperando
    User::create($data);
});

✅ Solução:

// Faça a operação lenta fora da transação
$data = fetchFromExternalAPI();

DB::transaction(function () use ($data) {
    User::create($data); // Rápido
});

❌ Armadilha 2: Ignorar Exceções

// NÃO FAÇA ISSO
try {
    DB::transaction(function () {
        Order::create(['total' => -100]); // Erro!
    });
} catch (Exception $e) {
    // "Vou ignorar e seguir em frente"
}

// Seu sistema continua inconsistente

❌ Armadilha 3: Transações Aninhadas Sem Cuidado

// Cada DB::transaction() é um novo nível
DB::transaction(function () { // Transação 1
    Order::create([...]);

    DB::transaction(function () { // Não é realmente uma transação aninhada!
        Payment::create([...]);
    });
});

✅ Use savepoints em vez disso:

DB::beginTransaction();
try {
    Order::create([...]);
    DB::savepoint(1);

    try {
        Payment::create([...]);
    } catch (Exception $e) {
        DB::rollbackToSavepoint(1);
        // Tenta algo diferente
    }

    DB::commit();
}

Monitoramento em Produção

Você está monitorando suas transações? Deveria estar:

// Listener customizado
Event::listen('illuminate.query', function ($query) {
    if ($query->getDurationInSeconds() > 5) {
        Log::warning('Slow transaction detected', [
            'sql' => $query->sql,
            'bindings' => $query->bindings,
            'time' => $query->getDurationInSeconds()
        ]);
    }
});

Ou use ferramentas como:

Datadog APM: monitora transações em produção
New Relic: identifica deadlocks
PostgreSQL logs: log_min_duration_statement = 1000 (queries > 1s)

Testando Transações

// Use RefreshDatabase do Laravel
class TransactionTest extends TestCase
{
    use RefreshDatabase;

    public function test_transaction_rollback()
    {
        $this->assertDatabaseCount('users', 0);

        try {
            DB::transaction(function () {
                User::create(['name' => 'João']);
                throw new Exception('Erro!');
            });
        } catch (Exception $e) {}

        $this->assertDatabaseCount('users', 0); // Rollback funcionou!
    }
}

Checklist Final: Você Está Fazendo Certo?

Transações apenas para operações que precisam de atomicidade
Operações lentas fora da transação
Nível de isolamento apropriado para o caso de uso
Tratamento de exceções adequado
Logs de transações falhadas
Monitoramento em produção
Testes de rollback
Timeout configurado

Próximos Passos

Transações são fundamentais, mas há mais:

Distributed Transactions: quando você tem múltiplos bancos
Event Sourcing: alternativa para auditoria
CQRS Pattern: separação leitura/escrita

Conclusão

Transações não são apenas um recurso técnico—são o fundamento da confiabilidade. Dominar seus conceitos, níveis de isolamento e armadilhas é o que separa código que "funciona" de código que é robusto.

Qual é sua maior dificuldade com transações? Compartilha nos comentários!

Quer mergulhar mais fundo?

ACID em Bancos de Dados: O Que É e Por Que Deveria Importar Para Você

André Moreira — Wed, 15 Jul 2026 18:30:42 +0000

ACID em Bancos de Dados: O Que É e Por Que Deveria Importar Para Você

Quando você está construindo uma aplicação que depende de dados, uma pergunta inevitável surge: como garantir que meus dados estejam sempre corretos e seguros? A resposta está em um acrônimo que virou padrão na indústria: ACID.

Neste artigo, vamos entender o que ACID significa, por que é importante e como isso afeta sua escolha de banco de dados.

O Que é ACID?

ACID é um conjunto de quatro propriedades que garantem a confiabilidade das transações em um banco de dados. Cada letra representa um princípio fundamental:

A - Atomicity (Atomicidade)
C - Consistency (Consistência)
I - Isolation (Isolamento)
D - Durability (Durabilidade)

Vamos explorar cada uma delas com exemplos práticos que fazem sentido no dia a dia.

🔄 Atomicity (Atomicidade)

A atomicidade garante que uma transação seja "tudo ou nada". Ou ela é completamente executada, ou não é executada em absoluto.

Imagine você transferindo R$ 100 de uma conta para outra em uma aplicação bancária:

1. Debita R$ 100 da conta A
2. Credita R$ 100 na conta B

Se algo der errado entre o passo 1 e 2 (queda de energia, erro na aplicação), o banco volta tudo ao estado anterior. Você não perde R$ 100 nem deixa de ganhar.

Sem atomicidade: Seu dinheiro desaparece, ou aparece em duas contas. Caos total.

Com atomicidade: Ou a transferência completa ou é revertida. Segurança garantida.

✅ Consistency (Consistência)

A consistência garante que o banco de dados sempre esteja em um estado válido. As regras que você definiu são sempre respeitadas.

Vamos dizer que você tem uma regra: "Todo usuário deve ter um email válido".

INSERT INTO users (name, email) VALUES ('João', 'email-inválido');

Sem consistência: O banco aceitaria esse dado inválido.

Com consistência: O banco rejeita a operação porque viola a regra definida.

A consistência protege a integridade dos seus dados. Constraints, triggers e validações garantem que nada "errado" entre no seu banco.

🔒 Isolation (Isolamento)

O isolamento garante que transações concorrentes não interfiram umas nas outras. Se duas operações acontecem ao mesmo tempo, uma não vê o estado parcial da outra.

Imagine dois usuários comprando o último produto em estoque simultaneamente:

Sem isolamento:

Usuário A verifica: 1 produto em estoque ✓
Usuário B verifica: 1 produto em estoque ✓
Ambos completam a compra... agora o estoque está em -1

Com isolamento:

Usuário A verifica: 1 produto ✓
Usuário B tenta a mesma coisa, mas o banco garante que só um consegue
Um leva, o outro recebe "produto fora de estoque"

💾 Durability (Durabilidade)

A durabilidade garante que os dados não vão sumir. Depois que você confirma uma transação, ela está gravada em pedra (praticamente).

Mesmo se seu servidor cair na próxima nanosegundo, aquele dado está salvo.

Sem durabilidade:

Você faz uma venda, confirma a transação
Servidor explode
Ninguém sabe que a venda aconteceu

Com durabilidade:

Você faz uma venda, confirma
Servidor explode
Os dados ainda lá estão, salvos permanentemente

Quando ACID Realmente Importa?

ACID é crítico quando:

✅ Dinheiro está envolvido (transações financeiras, pagamentos)
✅ Dados sensíveis precisam estar corretos (saúde, legal)
✅ Consistência é não-negociável (inventário, reservas)
✅ Seu negócio depende da confiabilidade dos dados

Menos crítico (mas ainda importante) quando:

⚠️ Você coleta analytics ou logs (algumas perdas são aceitáveis)
⚠️ Você trabalha com conteúdo de redes sociais (consistência eventual é ok)
⚠️ Você precisa de escalabilidade maciça em tempo real

Tabela Comparativa: Qual Banco Usar?

Banco de Dados	ACID	Tipo	Melhor Para	Escalabilidade
PostgreSQL	✅ Sim (Completo)	Relacional	Aplicações críticas, financeiro, SaaS	Vertical (com replicação)
MySQL/MariaDB	✅ Sim (Com InnoDB)	Relacional	Web apps, blogs, startups	Vertical (com replicação)
MongoDB	✅ Sim (Desde v4)	Documento	Dados semi-estruturados, prototipagem	Horizontal
SQLite	✅ Sim	Relacional	Apps simples, mobile, desktop	Apenas arquivo local
Oracle Database	✅ Sim (Completo)	Relacional	Grandes corporações, enterprise	Vertical/Horizontal
DynamoDB	⚠️ Parcial	Chave-valor	Aplicações serverless na AWS	Horizontal
Redis	❌ Não	Chave-valor	Cache, sessões, real-time	Horizontal (com cuidado)
Cassandra	❌ Não	Coluna-largura	Big data, grande escala	Horizontal

Exemplo Prático com Laravel/PHP

Se você está usando Laravel com PostgreSQL, está tendo ACID de graça:

DB::transaction(function () {
    $account = Account::find(1)->lockForUpdate();
    $account->balance -= 100;
    $account->save();

    $other = Account::find(2)->lockForUpdate();
    $other->balance += 100;
    $other->save();
});

Se algo errar dentro da transação, tudo volta. PostgreSQL garante:

Atomicity: Ou ambas contas são atualizadas ou nenhuma é
Consistency: As regras do seu modelo são respeitadas
Isolation: Outro user não consegue ler estado parcial
Durability: Depois do commit, aquilo não some

Consistência Eventual: O Trade-off

Alguns bancos NoSQL sacrificam ACID por velocidade e escalabilidade. Usam um modelo chamado "consistência eventual".

Significa: seus dados podem estar inconsistentes por alguns milissegundos, mas eventualmente ficarão consistentes.

Ideal para:

Contadores de views (quem liga se está 100% exato?)
Social media feeds
Análise de dados em larga escala

Não recomendo para:

Transações financeiras
Inventário de e-commerce
Qualquer coisa onde a precisão é vida ou morte

A Regra de Ouro

Se você está em dúvida, escolha ACID.

PostgreSQL e MySQL com InnoDB são extremamente rápidos e confiáveis. Você precisará de MUITA escala antes de realmente precisar abandonar ACID por NoSQL.

Comece simples. Escale quando necessário. Não sobre-engenharia.

Conclusão

ACID não é um conceito chato de livro de banco de dados. É a diferença entre um sistema que funciona confiável e um que perde dados aleatoriamente.

Entender ACID ajuda você a:

Escolher o banco de dados certo para seu projeto
Escrever código mais seguro
Evitar bugs sutis que aparecem em produção
Dormir melhor à noite sabendo que seus dados estão seguros

Próxima vez que alguém perguntar "Por que não usar NoSQL para tudo?", você tem a resposta. 😉

E você? Qual banco usa no seu projeto? Enfrentou algum problema relacionado a transações que ACID teria resolvido? Deixa nos comentários!

Git com múltiplas contas: configure trabalho e pessoal no mesmo computador

André Moreira — Wed, 24 Jun 2026 12:49:58 +0000

Você já fez um commit no repositório do trabalho e percebeu que estava com o seu e-mail pessoal? Ou o contrário? Esse é um dos erros mais comuns de quem usa Git com múltiplas contas no mesmo computador.

Neste tutorial você vai aprender a configurar tudo corretamente, de uma vez, usando chaves SSH separadas e .gitconfig condicional — sem gambiarras.

O problema

Por padrão o Git usa uma configuração global:

git config --global user.name "Seu Nome"
git config --global user.email "seu@email.com"

Isso significa que todos os repositórios no seu computador usam o mesmo usuário. Quando você tem contas separadas (ex: joao@empresa.com no GitLab da empresa e joao@gmail.com no GitLab pessoal), os commits vão sair com o e-mail errado.

A solução profissional envolve duas partes:

Chaves SSH separadas para cada conta
.gitconfig condicional que aplica o usuário certo — e a chave SSH certa — por pasta

Passo 1 — Gerar as chaves SSH

Abra o terminal e gere uma chave para cada conta. Use nomes diferentes para não sobrescrever:

# Chave para a conta pessoal
ssh-keygen -t ed25519 -C "joao@gmail.com" -f ~/.ssh/id_ed25519_pessoal

# Chave para a conta do trabalho
ssh-keygen -t ed25519 -C "joao@empresa.com" -f ~/.ssh/id_ed25519_trabalho

💡 Por que ed25519? É o algoritmo mais moderno, mais seguro e recomendado pelo GitHub, GitLab e Bitbucket. Evite RSA a menos que seu servidor seja muito antigo.

Ao final você terá quatro arquivos em ~/.ssh/:

id_ed25519_pessoal      ← chave privada (nunca compartilhe)
id_ed25519_pessoal.pub  ← chave pública (você registra no GitLab)
id_ed25519_trabalho
id_ed25519_trabalho.pub

Passo 2 — Registrar as chaves no GitLab

Para cada conta:

Copie o conteúdo da chave pública:

# Pessoal
cat ~/.ssh/id_ed25519_pessoal.pub

# Trabalho
cat ~/.ssh/id_ed25519_trabalho.pub

Acesse Settings → SSH and GPG keys → New SSH key na conta correspondente e cole o conteúdo.

Faça isso nas duas contas, cada uma com a sua respectiva chave pública.

Passo 3 — Configurar o Git por pasta (o pulo do gato)

Aqui está o diferencial: usar o includeIf do Git para aplicar configurações diferentes dependendo de onde o repositório está — incluindo qual chave SSH usar, sem precisar mexer no ~/.ssh/config.

A ideia é simples: você organiza seus projetos em pastas separadas:

~/
├── projetos/
│   ├── pessoal/       ← projetos pessoais
│   └── trabalho/      ← projetos da empresa

3.1 — Criar os `.gitconfig` específicos

Cada arquivo define o usuário e a chave SSH que o Git deve usar naquela pasta. O core.sshCommand instrui o Git a chamar o SSH com uma chave específica e ignorar qualquer configuração do ~/.ssh/config (o -F /dev/null garante isso):

# Configuração pessoal
cat > ~/.gitconfig-pessoal << 'EOF'
[user]
    name = João Silva
    email = joao@gmail.com
[core]
    sshCommand = ssh -i ~/.ssh/id_ed25519_pessoal -F /dev/null
EOF

# Configuração do trabalho
cat > ~/.gitconfig-trabalho << 'EOF'
[user]
    name = João Silva
    email = joao@empresa.com
[core]
    sshCommand = ssh -i ~/.ssh/id_ed25519_trabalho -F /dev/null
EOF

💡 O que é -F /dev/null? Diz ao SSH para ignorar completamente o ~/.ssh/config. Isso evita que configurações globais de SSH interfiram e garante que a chave especificada em -i seja a única usada. Sem essa flag, o SSH ainda pode carregar outras identidades do seu agente.

3.2 — Configurar o `.gitconfig` global com `includeIf`

Edite ~/.gitconfig:

vim ~/.gitconfig

Deixe assim:

[user]
    name = João Silva
    email = joao@gmail.com   # fallback (usado fora das pastas mapeadas)

[includeIf "gitdir:~/projetos/pessoal/"]
    path = ~/.gitconfig-pessoal

[includeIf "gitdir:~/projetos/trabalho/"]
    path = ~/.gitconfig-trabalho

⚠️ A barra no final do caminho é obrigatória. ~/projetos/trabalho/ funciona; ~/projetos/trabalho não.

Passo 4 — Testar a conexão SSH

Com os .gitconfig configurados, o teste correto é deixar o Git invocar o SSH automaticamente — sem passar a chave no comando.

O detalhe importante: o includeIf só é ativado dentro de um repositório git. Por isso o teste cria um repo temporário dentro de cada pasta mapeada e roda git ls-remote, que faz uma conexão SSH real sem precisar de nenhum clone:

# Crie as pastas base se ainda não existirem
mkdir -p ~/projetos/pessoal ~/projetos/trabalho

# Teste da conta pessoal
cd ~/projetos/pessoal
git init .teste-pessoal && cd .teste-pessoal
git ls-remote git@gitlab.com:joao-pessoal/meu-projeto.git HEAD
# deve listar o HEAD autenticado como joao-pessoal
cd .. && rm -rf .teste-pessoal

# Teste da conta do trabalho
cd ~/projetos/trabalho
git init .teste-trabalho && cd .teste-trabalho
git ls-remote git@gitlab.com:empresa/projeto-empresa.git HEAD
# deve listar o HEAD autenticado como conta da empresa
cd .. && rm -rf .teste-trabalho

💡 O git init dentro da pasta é necessário porque o includeIf "gitdir:..." só é avaliado quando o Git está operando dentro de um repositório. O ls-remote faz a conexão SSH sem precisar de histórico ou commits — é o teste mais leve possível.

Se aparecer Permission denied (publickey), volte ao Passo 2 e verifique se a chave pública foi cadastrada na conta correta.

Passo 5 — Clonar repositórios

Com essa abordagem, as URLs de clone continuam normais — você usa git@gitlab.com em todos os casos. O Git saberá qual chave usar com base na pasta onde o repositório está:

# Repositório pessoal — clone normalmente dentro de ~/projetos/pessoal/
git clone git@gitlab.com:joao-pessoal/meu-projeto.git ~/projetos/pessoal/meu-projeto

# Repositório do trabalho — clone dentro de ~/projetos/trabalho/
git clone git@gitlab.com:empresa/projeto-empresa.git ~/projetos/trabalho/projeto-empresa

Para repositórios já clonados fora da pasta certa, mova-os para a pasta correta ou defina o sshCommand manualmente só naquele repo:

cd ~/algum-repo-avulso
git config core.sshCommand "ssh -i ~/.ssh/id_ed25519_trabalho -F /dev/null"
git config user.email "joao@empresa.com"

Verificação final

Dentro de cada repositório, confirme que o Git está usando o usuário e a chave corretos:

cd ~/projetos/trabalho/projeto-empresa
git config user.email
# deve retornar: joao@empresa.com

git config core.sshCommand
# deve retornar: ssh -i ~/.ssh/id_ed25519_trabalho -F /dev/null

cd ~/projetos/pessoal/meu-projeto
git config user.email
# deve retornar: joao@gmail.com

Resumo da estrutura

~/.ssh/
├── id_ed25519_pessoal        ← chave privada pessoal
├── id_ed25519_pessoal.pub
├── id_ed25519_trabalho       ← chave privada do trabalho
└── id_ed25519_trabalho.pub

~/.gitconfig                  ← config global com includeIf
~/.gitconfig-pessoal          ← user, email e sshCommand pessoal
~/.gitconfig-trabalho         ← user, email e sshCommand do trabalho

~/projetos/
├── pessoal/                  ← clones pessoais aqui
└── trabalho/                 ← clones do trabalho aqui

Problemas comuns

"Still using the wrong email after setup"
Verifique se a barra final está no includeIf. Rode git config user.email dentro do repositório (não globalmente).

"Permission denied (publickey)"
Rode ssh -i ~/.ssh/id_ed25519_trabalho -vT git@gitlab.com para ver o que acontece. Confirme que a chave pública está cadastrada na conta correta no GitLab.

"sshCommand não está sendo aplicado"
Confirme que o repositório está dentro da pasta mapeada no includeIf e que a barra final está presente. Teste com git config core.sshCommand dentro do repo.

Conclusão

Com essa configuração você nunca mais vai:

❌ Commitar com o e-mail errado
❌ Misturar credenciais de contas diferentes
❌ Precisar criar aliases de host no ~/.ssh/config
❌ Precisar configurar manualmente cada repositório

A lógica é elegante: o includeIf do Git ativa automaticamente o user, o email e o core.sshCommand certos com base na pasta — tudo em um único lugar, sem efeitos colaterais no restante do sistema.

Gostou? Deixa uma reação e compartilha com aquele dev que sempre commita com o e-mail errado 👇

DEV Community: André Moreira

Dominando Transações de Banco de Dados: Do Conceito à Prática com Laravel

Dominando Transações de Banco de Dados: Do Conceito à Prática com Laravel

O Problema Real

Conceitos Fundamentais: ACID

Atomicidade (A)

Consistência (C)

Isolamento (I)

Durabilidade (D)

Níveis de Isolamento: O Trade-off

Na Prática com Laravel

1. Transação Básica

2. Controle Manual com Savepoints

3. Definindo Nível de Isolamento

4. Timeout de Transação

Armadilhas Comuns (e como evitá-las)

❌ Armadilha 1: Transações Muito Longas

❌ Armadilha 2: Ignorar Exceções

❌ Armadilha 3: Transações Aninhadas Sem Cuidado

Monitoramento em Produção

Testando Transações

Checklist Final: Você Está Fazendo Certo?

Próximos Passos

Conclusão

ACID em Bancos de Dados: O Que É e Por Que Deveria Importar Para Você

ACID em Bancos de Dados: O Que É e Por Que Deveria Importar Para Você

O Que é ACID?

🔄 Atomicity (Atomicidade)

✅ Consistency (Consistência)

🔒 Isolation (Isolamento)

💾 Durability (Durabilidade)

Quando ACID Realmente Importa?

Tabela Comparativa: Qual Banco Usar?

Exemplo Prático com Laravel/PHP

Consistência Eventual: O Trade-off

A Regra de Ouro

Conclusão

Git com múltiplas contas: configure trabalho e pessoal no mesmo computador

O problema

Passo 1 — Gerar as chaves SSH

Passo 2 — Registrar as chaves no GitLab

Passo 3 — Configurar o Git por pasta (o pulo do gato)

3.1 — Criar os .gitconfig específicos

3.2 — Configurar o .gitconfig global com includeIf

Passo 4 — Testar a conexão SSH

Passo 5 — Clonar repositórios

Verificação final

Resumo da estrutura

Problemas comuns

Conclusão

3.1 — Criar os `.gitconfig` específicos

3.2 — Configurar o `.gitconfig` global com `includeIf`