Shopify substituiu Redis por MySQL para reservas de estoque — e isso escalou
O post de engenharia da Shopify sobre substituir o Redis por MySQL para reservas de estoque gera debate sobre os trade-offs entre uma única store transacional e um design de dois sistemas usando Redis para contadores rápidos. Os comentadores dissecam a abordagem em MySQL — uma linha por unidade reservável com SKIP LOCKED e um buffer limitado — questionando sua complexidade, escalabilidade sob carga estilo flash sale, e se esquemas mais simples baseados em carrinho ou Redis seriam suficientes. Um fio paralelo critica o uso pesado de conteúdo técnico gerado por IA pela empresa e levanta preocupações sobre a cultura e a política da liderança da Shopify, com alguns leitores dizendo que isso mina sua confiança na produção de engenharia da firma.
Percepção da liderança e da cultura da Shopify
- Vários comentadores se concentram na política da liderança, alegando apoio a causas de extrema direita e visões controversas sobre voto e imigração.
- Alguns descrevem experiências negativas de trabalho: tolerância a insultos e comportamento grosseiro, contratação de pessoas “descoladas” sem perfil técnico, e uma cultura que empurra fortemente o uso de IA.
- Outros pedem evidências mais concretas, ligam para cobertura crítica da mídia ou descartam o ângulo político como irrelevante para um post técnico.
Post de blog escrito por IA e preocupações com “slop”
- Muitos acreditam que o post de engenharia foi em grande parte escrito por LLM, apontando para o estilo: muitos travessões, estrutura em listas, slogans e “LLM-isms” como frases contrastivas de impacto.
- Alguns acham o texto legível e informativo; outros dizem que o estilo é verboso, de baixa densidade e mais difícil de entender do que a escrita técnica humana.
- Há frustração mais ampla com empresas publicando conteúdo polido por IA em vez da própria voz dos engenheiros, e com o tom da IA se infiltrando na escrita humana.
MySQL vs Redis, e consolidação em SQL
- Alguns concordam com substituir o Redis: manter dois sistemas de armazenamento adiciona complexidade, especialmente se a verdade do estoque já vive em SQL.
- Outros argumentam que Redis é excelente para sistemas de reserva, escala bem sob alta concorrência e poderia ser o principal para estoque sem sincronização com SQL.
- Há debate sobre durabilidade e transações no Redis: um lado enfatiza sua persistência e recursos transacionais; outro observa queda de desempenho com fsync rigoroso e a falta de ferramentas de SQL.
Uma linha por unidade com SKIP LOCKED e buffer pool
- O desenho — buffers limitados de uma linha por unidade para cada item/local,
SELECT … FOR UPDATE SKIP LOCKED, e um job de reabastecimento — é visto por alguns como uma forma inteligente de repartir a contenção de locks entre linhas. - Outros acham o buffer de 1.000 linhas e o reabastecimento “desajeitados” ou um “cheiro de algoritmo”, preocupando-se com complexidade e casos extremos.
Desenhos alternativos e trade-offs de UX
- Alternativas propostas incluem: uma linha por carrinho–SKU, reservar no checkout em vez do pagamento, GC em background de carrinhos abandonados, ou engines de workflow/objetos duráveis para coordenação por item.
- Críticos argumentam que muitas alternativas ainda centralizam a contenção em uma única linha agregada ou exigem sistemas extras.
- Há discordância sobre quando reservar o estoque: cedo (no carrinho/checkout) para melhor UX vs tarde (no pagamento) para evitar acúmulo em carrinhos abandonados e vendas perdidas.
Temas arquiteturais mais amplos
- Debates em andamento: microserviços vs simplicidade de um único banco, SQL vs NoSQL, e se grandes empresas devem construir motores de dados personalizados em vez de depender do MySQL.