We replaced Redis with MySQL for inventory reservations and it scaled
Shopify’s engineering post on replacing Redis with MySQL for inventory reservations prompts debate over the tradeoffs between a single transactional data store and a dual-system design using Redis for fast counters. Commenters dissect the proposed MySQL approach — one row per reservable unit with SKIP LOCKED and a capped buffer — questioning its complexity, scalability under flash-sale–style load, and whether simpler cart- or Redis-based schemes would suffice. A parallel thread criticizes the company’s heavy use of AI-generated technical content and raises concerns about Shopify’s leadership culture and politics, with some readers saying this undermines their trust in the firm’s engineering output.
Perception of Shopify leadership and culture
- Several commenters focus on leadership’s politics, alleging support for far‑right causes and controversial views on voting and immigration.
- Some describe negative work experiences: tolerance of slurs and crude behavior, hiring “cool” nontechnical people, and a culture heavily pushing AI usage.
- Others ask for more concrete evidence, link to critical media coverage, or dismiss the political angle as irrelevant to a technical post.
AI-written blog post and “slop” concerns
- Many believe the engineering blog post is largely LLM-written, pointing to style: em‑dash heavy, listy structure, slogans, and “LLM-isms” like punchy contrastive phrases.
- Some find it readable and informative; others say the style is verbose, low-density, and harder to parse than human technical writing.
- There’s broader frustration that companies publish AI-polished content instead of engineers’ own voices, and that AI tone is bleeding into human writing.
MySQL vs Redis, and consolidation on SQL
- Some agree with replacing Redis: maintaining two storage systems adds complexity, especially if inventory truth already lives in SQL.
- Others argue Redis is excellent for reservation systems, scales well under high concurrency, and could be primary for stock without SQL sync.
- There’s debate over Redis durability and transactions: one side stresses its persistence and transactional features; another notes performance drops with strict fsync and the lack of SQL tooling.
Row-per-unit with SKIP LOCKED and buffer pool
- The design—capped one-row-per-unit buffers per item/location,
SELECT … FOR UPDATE SKIP LOCKED, and a replenishment job—is seen by some as clever sharding of lock contention across rows. - Others find the 1,000-row buffer and replenishment “clunky” or an “algorithmic smell,” worrying about complexity and edge cases.
Alternative designs and UX trade-offs
- Proposed alternatives include: one row per cart–SKU, reserving at checkout rather than payment, background GC of abandoned carts, or workflow engines/durable objects for per-item coordination.
- Critics argue many alternatives still centralize contention on a single aggregate row or require extra systems.
- There’s disagreement on when to reserve stock: early (on cart/checkout) for better UX vs late (on payment) to avoid abandoned-cart hoarding and lost sales.
Broader architectural themes
- Ongoing debates: microservices vs single-DB simplicity, SQL vs NoSQL, and whether large firms should build custom data engines instead of relying on MySQL.