Como a Shopify substituiu o Redis pelo Banco Relacional (e por que você deveria olhar para o PostgreSQL)
Na engenharia de software, existe um mito de que, para escalar sistemas de alta concorrência, você precisa obrigatoriamente adicionar camadas de cache distribuído e infraestruturas complexas. Recentemente, a Shopify desafiou essa crença ao realizar o que muitos chamam de "o grande rollback": eles removeram o Redis de partes críticas de sua gestão de estoque e voltaram a confiar puramente no banco de dados relacional.
O resultado? O sistema segurou um volume impressionante de 5,1 milhões de dólares processados por minuto na Black Friday de 2025, provando que a simplicidade arquitetural pode ser imbatível quando conhecemos profundamente as nossas ferramentas.
O Problema Clássico: Concorrência Fantasma
O problema que a Shopify precisava resolver é antigo na computação: dois usuários tentam comprar o mesmo tênis ao mesmo tempo, existindo apenas uma unidade em estoque. Se o sistema falhar ao gerenciar essa concorrência, ambos pagam pelo mesmo produto (gerando reclamações e cancelamentos) ou o sistema recusa a venda por segurança e perde faturamento.
Para resolver isso, a arquitetura antiga da Shopify utilizava o Redis como um "caixa rápido" para reservar os itens temporariamente, enquanto o estoque de verdade ficava armazenado no MySQL. No entanto, manter esses dois sistemas sincronizados em tempo real gerava um enorme gargalo. O sistema precisava atualizar o MySQL e, em seguida, limpar o Redis em transações separadas.
Se ocorresse uma falha de comunicação entre essas etapas, acontecia o efeito "estoque fantasma": o item aparecia bloqueado no banco sem ter sido vendido, ou era vendido sem dar a baixa correspondente.
A Mudança de Paradigma: De Colunas para Linhas
Tradicionalmente, modelamos o estoque usando uma tabela com uma coluna de quantidade (ex: quantidade: 10). Quando ocorre uma compra, o banco bloqueia essa linha inteira para subtrair um item. Se milhares de pessoas tentam comprar o mesmo item ao mesmo tempo, cria-se uma fila imensa de conexões esperando o desbloqueio.
A Shopify mudou completamente essa lógica:
- Estoque físico como linhas: Cada unidade física de um produto virou uma linha individual no banco de dados. Se você tem 10 tênis no estoque, você tem 10 linhas na tabela.
- Reserva atômica: Reservar três tênis significa simplesmente buscar, atualizar e bloquear três linhas específicas, tudo dentro de uma única transação atômica.
Para evitar que as tabelas crescessem infinitamente com produtos de altíssimo estoque, eles adotaram a estratégia de criar um pool limitado de até 1.000 linhas por produto e localização, reabastecendo essa banca de forma automática à medida que os itens eram vendidos.
O Segredo: A Cláusula SKIP LOCKED
A engrenagem que faz essa arquitetura funcionar sem travar o banco de dados é a funcionalidade SKIP LOCKED.
Imagine que o banco de dados é um funcionário do estoque buscando uma caixa. Se outro cliente já está segurando aquela caixa (linha travada por outra transação), o funcionário não fica parado esperando o desbloqueio. Com o SKIP LOCKED, ele pula imediatamente as linhas bloqueadas e pega a próxima caixa disponível na prateleira.
- Funcionamento no MySQL
No MySQL (disponível desde a versão 8.0, lançada em 2018), a cláusula SELECT ... FOR UPDATE SKIP LOCKED permitiu à Shopify eliminar a dependência do Redis. No entanto, para chegar lá, eles precisaram resolver três problemas clássicos:
- Ajustar chaves privadas mal desenhadas que geravam travamentos duplos;
- Desativar o comportamento padrão do MySQL que bloqueava espaços vazios ao redor da linha (gap locks);
- Corrigir transações que se travavam mutuamente devido à ordem das operações.
Depois dessas otimizações e de limpar gargalos que monopolizavam conexões no checkout, eles reduziram as leituras do banco em 50%, as transações em 33% e mantiveram a CPU do MySQL abaixo de 50% nos picos da Black Friday.
- Funcionamento no PostgreSQL
Muitos desenvolvedores não sabem, mas se você utiliza o PostgreSQL, você tem essa exata funcionalidade nativa desde a versão 9.5.
No Postgres, o comando funciona de forma idêntica e extremamente limpa:
-- Busca e reserva 1 item de estoque disponível, ignorando os que já estão em processo de compra SELECT id FROM estoque WHERE produto_id = 101 AND status = 'disponivel' LIMIT 1 FOR UPDATE SKIP LOCKED;
Se o Usuário A e o Usuário B executarem essa query no mesmo milissegundo, o Postgres entregará o primeiro ID para o Usuário A, travará essa linha e, em vez de fazer o Usuário B esperar, pulará para o próximo ID disponível para o Usuário B instantaneamente.
Vantagens de Manter Tudo no Banco Relacional
- Atomicidade e Consistência (ACID): A reserva de estoque e o checkout acontecem sob a mesma transação. Não há risco de inconsistência; ou tudo funciona ou tudo sofre rollback.
- Simplicidade de Infraestrutura: Menos um cluster (Redis) para configurar, monitorar, replicar, pagar e depurar.
- Menor Carga Cognitiva: Sua aplicação conversa com uma única fonte da verdade, facilitando a manutenção e a sanidade do time de engenharia.
Inspirada por movimentos de simplificação como o da 37signals (criadores do Basecamp), a decisão da Shopify prova que, muitas vezes, as soluções para os nossos maiores problemas de escala já estão nativas dentro dos bancos de dados que já utilizamos no dia a dia.
Créditos e Referências
Este artigo foi fortemente inspirado nas discussões e análises técnicas trazidas pelo canal mano deyvin, que questiona o uso automático de ferramentas complexas ("da moda") quando soluções nativas e robustas já estão ao nosso alcance de graça.
Assista à análise técnica completa e bem-humorada diretamente no YouTube: 📺 Assista ao vídeo: "todo mundo aceitou. um dev questionou." no YouTube