Em maio de 2026, a engenharia da Shopify publicou um relato que contraria quase todo instinto moderno de infraestrutura: a empresa tirou o Redis do caminho crítico das reservas de inventário e colocou o MySQL no lugar. O resultado não foi um recuo técnico, foi escala. Durante a Black Friday de 2025, a plataforma registrou um pico recorde de 5,1 milhões de dólares em vendas por minuto, e cada uma dessas transações passou pelo controle de estoque.
O caso ganhou tração porque mexe com uma crença confortável. Diante de um gargalo de concorrência, o reflexo do mercado é alcançar a ferramenta do momento: um cache em memória, uma camada de mensageria, um coordenador sob medida. Foi essa reação automática que um vídeo do canal mano deyvin resumiu bem no título, "todo mundo aceitou, um dev questionou". A pergunta que sustenta o episódio inteiro é simples e incômoda: o que existe na sua stack que ninguém nunca questionou?
Escalar um sistema crítico raramente é sobre comprar mais máquina. É sobre modelar dados com precisão, entender o comportamento transacional de ponta a ponta e ter a coragem de revisitar decisões antigas quando o contexto muda. A Shopify não venceu a Black Friday dobrando a infraestrutura de cache. Venceu voltando a um banco relacional clássico, redesenhando o modelo de dados para reduzir contenção e ajustando o nível de isolamento das transações que importavam.
Este texto percorre o que a Shopify fez, por que funcionou e, principalmente, qual lição sobra para quem projeta software. Porque a parte mais reveladora do caso não está no banco de dados. Está em um gargalo que ninguém tinha percebido, escondido em um lugar que ninguém estava olhando.
O problema: garantir o último par de tênis
Quando o comprador clica em "finalizar compra", o sistema precisa garantir que o item ainda está disponível. Errar para um lado significa vender a mesma última unidade para dois clientes, o que obriga o lojista a cancelar o pedido, pedir desculpas e absorver o custo de suporte. Errar para o outro significa dizer que algo esgotou quando ainda havia estoque, e aí o lojista perde uma venda que era dele. A proteção contra overselling da Shopify resolve isso com duas operações: a reserva, um bloqueio curto que segura a unidade durante o processamento do pagamento, e a baixa definitiva, que deduz a quantidade do livro-razão de inventário quando o pagamento é aprovado.
Por que o Redis chegou ao limite
Durante anos, essas reservas rodaram em Redis. Cada item tinha uma chave de quantidade, reservar era um DECR, liberar era um INCR. O Redis dava conta da concorrência, mas as reservas e o livro-razão viviam em sistemas diferentes. A baixa definitiva exigia atualizar o MySQL e limpar o Redis, e essas duas operações não cabiam em um único passo atômico. Dependendo da ordem, o resultado era overselling ou underselling. Somava-se a isso a ausência de consciência de múltiplas localizações e o custo operacional de manter um cluster separado. Trazer as reservas para o mesmo banco do livro-razão permitiria envolver tudo em transações ACID e eliminar essas falhas na origem.
A virada: uma linha por unidade e o SKIP LOCKED
Tentativas anteriores tinham falhado, porque uma única linha com uma coluna de quantidade não suportava a contenção. O recurso SKIP LOCKED, do MySQL 8, abriu um desenho diferente: uma linha por unidade vendável em vez de uma linha por item. Um item com dez unidades vira dez linhas, e reservar três unidades é selecionar e mover três linhas na mesma transação. O SKIP LOCKED é o que torna isso escalável, porque, se outra transação já travou algumas linhas, o MySQL as ignora e devolve outras disponíveis, sem espera na mesma linha e com muito menos contenção. Para não explodir a tabela, a Shopify mantém um pool limitado a mil linhas por combinação de item e localização, reabastecido a partir do livro-razão. Quando o pool esvazia em uma queima de estoque, o reabastecimento acontece na hora, protegido por um lock que evita o efeito manada. Isso adiciona latência àquela reserva específica, mas preserva a correção: quem tem estoque disponível nunca é recusado.
Os detalhes que decidem: locks, isolamento e ordem
A engenharia fina apareceu nos detalhes. O primeiro protótipo usava uma chave primária autoincremental e travava duas linhas por reserva, porque o InnoDB bloqueava o índice secundário e o índice agrupado. A troca por uma chave primária composta, com as colunas de filtro dentro dela, reduziu para um lock por linha. Em seguida, o SELECT ... FOR UPDATE SKIP LOCKED em uma tabela vazia gerava gap locks que travavam o reabastecimento, então o time mudou o isolamento de REPEATABLE READ para READ COMMITTED naquelas transações. Deadlocks surgiam quando reserva e baixa tocavam duas tabelas em ordens diferentes, resolvidos com uma ordem de acesso padronizada. Por fim, o uso de UNION ALL juntou várias reservas em uma única ida ao banco, cortando idas e vindas e aliviando a latência sob carga.
O gargalo real: conexões, não CPU
Aqui está a parte que muda a conversa. Mesmo com as consultas otimizadas, a produção bateu em um teto de throughput bem abaixo da meta. A latência estava aceitável, a CPU não estava saturada, e ainda assim as threads enfileiravam no MySQL e as conexões se esgotavam na camada do ProxySQL. Saber que as conexões acabaram não diz quem as está segurando. O time então anotou cada consulta com um comentário identificando o processo de negócio, algo como /* conn_tag:checkout_completion */, e passou a medir no ProxySQL quanto tempo cada chamador retinha uma conexão. A resposta apareceu na hora: as reservas não eram as vilãs, outras partes do checkout seguravam conexões por tempo demais e nunca tinham sido otimizadas, porque nunca tinham sido as primeiras a bater no limite. A limpeza desse caminho removeu metade das leituras e um terço das transações no banco primário. Uma configuração de concorrência de threads do InnoDB, definida de forma conservadora anos antes e nunca revista, ainda segurava capacidade ociosa. Ajustados os dois pontos, o teto sumiu.
Foi um investigador humano, apoiado em observabilidade dirigida, que ligou a retenção de recurso ao processo de negócio certo. Nesse tipo de investigação, um parceiro de raciocínio ajuda a andar mais rápido: uso o Claude para interpretar a saída de um SHOW ENGINE INNODB STATUS, cruzar hipóteses sobre gap locks e revisar um modelo de dados antes de ele ir para produção. A ferramenta acelera o entendimento, desde que a decisão continue sendo sua.
O caso condensa quatro verdades que valem para qualquer projeto técnico. A primeira é que força bruta não conserta arquitetura equivocada: aumentar o cluster para sustentar um código transacional mal escrito apenas adia e encarece o desastre, porque o gargalo migra para o próximo componente mais fraco. A segunda é que sistemas não existem no vácuo. Ter a rotina mais performática da empresa é irrelevante se o módulo ao lado segura conexões de forma indefinida e derruba o ecossistema. A análise de desempenho precisa ser sistêmica, de ponta a ponta.
A terceira é a complexidade acidental. Se o banco relacional domina o problema com recursos nativos como o SKIP LOCKED, que também existe no PostgreSQL, empilhar uma camada de mensageria ou um banco em memória só amplia a superfície de erro e o custo de manutenção. A quarta é a diferença entre métrica de vaidade e telemetria dirigida. Monitorar uso de CPU não diagnostica nada sozinho. Sem observabilidade que conecte a retenção de recursos aos processos do negócio, toda ação corretiva vira palpite.
A maturidade em desenvolvimento não vem de dominar a ferramenta mais recente. Vem de projetar modelos de dados resilientes, gerenciar o estado transacional de ponta a ponta e ter o pragmatismo de entender que solução eficiente nasce da dor do negócio, e raramente do uso irracional de infraestrutura. A pergunta do vídeo continua valendo depois que a leitura termina: o que existe na sua stack que ninguém questiona?
Para conversas sobre arquitetura, engenharia e IA aplicada, acompanhe o Canal Nexa e a Seleção Vip.
Referências: NOEL, Emilie. We replaced Redis with MySQL for inventory reservations and it scaled. Shopify Engineering, 12 maio 2026. Disponível em: https://shopify.engineering/scaling-inventory-reservations. · MANO DEYVIN. todo mundo aceitou. um dev questionou. YouTube, 3 jun. 2026.