CEVIU Logo
Voltar
Shopify substitui Redis por MySQL para reserva de inventário, escalando operações críticas

Shopify migra sistema de reservas de inventário do Redis para MySQL em busca de robustez e escalabilidade

Aprofundamento CEVIU

Aprofundamento

A migração do sistema de reserva de inventário da Shopify, saindo do Redis para o MySQL, representa um avanço técnico significativo. O desafio era conciliar picos de demanda, como a Black Friday (que em 2025 registrou 5.1 milhões de dólares por minuto em vendas), com a necessidade de consistência e escalabilidade. O Redis, embora rápido, não garantia a atomicidade nas operações de reserva e dedução de estoque, pois o inventário principal estava no MySQL. Essa separação gerava risco de overselling ou underselling.

A solução encontrada, inspirada por uma abordagem de 37signals, baseou-se no recurso SKIP LOCKED do MySQL 8. Em vez de uma única linha por item com uma coluna de quantidade, a Shopify adotou uma linha por unidade de inventário. Reservar três itens significa selecionar e mover três linhas numa única transação, tudo dentro do MySQL, garantindo as propriedades ACID. O SKIP LOCKED permite que outras transações ignorem linhas bloqueadas, reduzindo a contenção. O sistema também implementou chaves primárias compostas, nível de isolamento READ COMMITTED e ordenação consistente de locks para evitar deadlocks, além de batching com UNION ALL para otimizar as consultas.

Um ponto crucial e revelador foi a descoberta de que o gargalo real não era a performance da consulta ou a CPU, mas o esgotamento de conexões no banco de dados. A Shopify instrumentou o código com tags de comentário (ex: /* conn_tag:checkout_completion */) e monitorou no ProxySQL o tempo de retenção de conexão por processo. Isso revelou que outras partes do fluxo de checkout estavam segurando conexões por tempo excessivo, impactando indiretamente o subsistema de reservas. A otimização dessas outras partes e o ajuste fino de configurações do MySQL, como a concorrência de threads, foram decisivos para alcançar os objetivos de escala.

O que mudou

A transição do Redis para o MySQL marcou uma mudança fundamental na abordagem da Shopify para as reservas de inventário. Anteriormente, as reservas eram gerenciadas no Redis, enquanto o inventário principal estava no MySQL. Essa arquitetura dual impedia transações atômicas entre os dois sistemas, abrindo brechas para inconsistências como overselling (vender o que não tem) ou underselling (não vender o que tem). O Redis também carecia de multi-location awareness e adicionava complexidade operacional.

Com a nova arquitetura no MySQL, especialmente habilitada pelo SKIP LOCKED do MySQL 8, o que antes era um problema de atomicidade agora é solucionado. A Shopify conseguiu consolidar todo o ciclo de vida da reserva e do inventário no mesmo banco de dados. Isso possibilitou transações totalmente ACID, eliminando os modos de falha anteriores. A empresa demonstrou que novas funcionalidades em bancos de dados relacionais podem viabilizar soluções que antes exigiriam infraestrutura especializada, como um key-value store separado.

Por que isso importa

A decisão da Shopify em migrar suas reservas de inventário para o MySQL mostra que bancos de dados relacionais modernos, com recursos avançados e uma arquitetura bem planejada, podem ser mais eficientes e robustos do que soluções distribuídas para certas cargas de trabalho de alta demanda. Isso desafia a percepção de que todo problema de escala exige um banco NoSQL ou um sistema distribuído complexo. Para a comunidade de desenvolvimento, é uma validação da resiliência e adaptabilidade do MySQL.

Este caso reforça a importância de um entendimento profundo do banco de dados e do sistema como um todo. A descoberta do gargalo nas conexões, em vez das consultas ou CPU, é uma lição valiosa sobre a complexidade da otimização em larga escala. Conforme discutido em matérias anteriores do CEVIU News, como a migração do particionamento de banco de dados da Etsy para Vitess em 24 de março de 2026, ou o desenvolvimento de novos key-value stores pelo Airbnb em 26 de fevereiro de 2026, empresas de tecnologia continuam a buscar soluções inovadoras e customizadas para seus desafios de dados, mesmo que isso signifique revisitar e aprimorar ferramentas já consolidadas.

Linha do tempo

  1. Airbnb constrói novo Key-Value Store

  2. Airtable reescreve seu banco de dados em Rust

  3. Etsy migra particionamento de banco de dados para Vitess

  4. Airbnb constrói sistema de armazenamento de métricas tolerante a falhas

  5. Engenharia da Zalando escala balanceamento de carga no lado do cliente

  6. Shopify impulsiona performance do checkout com Componentes Web Polaris e IA

  7. Shopify migra sistema de reservas do Redis para MySQL

Perguntas frequentes

Qual foi o principal problema que a Shopify buscava resolver com a nova arquitetura de reservas?

A Shopify queria garantir a atomicidade e consistência nas reservas de inventário, especialmente em momentos de pico. O sistema anterior, com reservas no Redis e inventário no MySQL, não permitia transações ACID completas, levando a riscos de overselling (venda acima do estoque) ou underselling (perda de vendas por indisponibilidade incorreta).

Como o recurso `SKIP LOCKED` do MySQL contribuiu para essa solução?

O `SKIP LOCKED` do MySQL 8 foi fundamental porque permitiu uma nova modelagem: uma linha por unidade de inventário. Ele possibilita que uma transação de reserva selecione unidades disponíveis enquanto outras transações ignoram unidades já bloqueadas, reduzindo a contenção e aumentando a vazão sem comprometer a consistência dos dados.

Qual foi o gargalo inesperado descoberto durante a otimização?

A Shopify descobriu que o principal gargalo não era a performance das consultas ou o uso da CPU, mas sim o esgotamento das conexões ao banco de dados. Outras partes do fluxo de checkout estavam mantendo conexões abertas por tempo excessivo, afetando a disponibilidade para o sistema de reservas e o desempenho geral.

Que estratégia de migração a Shopify utilizou para garantir a segurança da transição?

A Shopify empregou um 'shadow mode', onde tanto o Redis quanto o MySQL recebiam as reservas em paralelo, com o Redis permanecendo como a fonte da verdade. Isso permitiu validar o MySQL em produção real, comparando os resultados. Após a validação, a fonte da verdade foi gradualmente alterada para o MySQL, com um kill switch para reverter ao Redis, caso necessário.

Fontes

Avalie este artigo:
Compartilhar:
Categoria
CEVIU Web Dev
Publicado
10 de agosto de 2026
Editoria
CEVIU Web Dev

Quer receber mais sobre CEVIU Web Dev?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser