Shopify replaced Redis with MySQL for inventory reservations at scale
Shopify rebuilt its oversell protection system using MySQL instead of Redis, handling record Black Friday 2025 traffic of $5.1M in sales per minute.
Conversation activity · last 29 hours peak 2/hr
Summary, timeline and people extracted by Claude from 12 items across 2 sources · 9h ago. Quotes are verbatim.
Shopify migrated its inventory reservation system from Redis to MySQL, leveraging MySQL 8's SKIP LOCKED feature to handle concurrent checkout operations at massive scale. The move unified their database strategy while maintaining ACID guarantees and preventing both overselling and underselling during peak traffic events like Black Friday 2025, which saw an 11% year-over-year increase in sales per minute.
- Shopify successfully migrated inventory reservations from Redis to MySQL using MySQL 8's SKIP LOCKED feature for concurrent access.
- The new system maintains ACID guarantees between reservations and the inventory ledger while supporting multi-location inventory awareness.
- The migration handled Black Friday 2025 peak traffic of $5.1M sales/minute without dropping requests or breaking consistency.
- The real bottleneck identified was not what was initially observed and measured, suggesting deeper architectural insights beyond the database choice.
How it unfolded
-
Reaction Hacker News discussion begins
The post reached Hacker News frontpage with 285 points and 187 comments, generating developer discussion about the architecture decision.
-
Report Shopify engineering post published
Shopify published a detailed technical post explaining how they replaced Redis with MySQL for inventory reservations and what they learned from the migration.
- 36 weeks quiet
-
Event Black Friday 2025 record traffic
Shopify merchants hit a record $5.1 million in sales per minute at peak, representing an 11% increase over the prior year.
What people are saying verbatim
“During checkout, when a buyer clicks "Complete purchase," we need to guarantee the items they're buying are still available.”
Shopify engineering · Shopify engineering blog · Aug 7
“If we get this wrong in one direction, two buyers purchase the same last unit: the merchant has to cancel an order, send an apology email, and eat the support cost.”
Shopify engineering · Shopify engineering blog · Aug 7
“On Black Friday 2025, merchants on our platform hit a record $5.1 million in sales per minute at peak.”
Shopify engineering · Shopify engineering blog · Aug 7
“The hardest lesson wasn't about database design. It was discovering that the real bottleneck wasn't what we were observing and measuring.”
Shopify engineering · Shopify engineering blog · Aug 7
Voices from the web unedited
-
I wonder how we could handle that in a simpler way with durable workflows (e.g. Temporal, Restante, DBOS) – which are similar to Erlang processes but with persistent disk storage. This could avoid the need to maintain the 1000 row inventory.Perhaps each shopping cart would have its own workflow, and the inventory item would have one as well. Then…
-
> Instead of one row per item with a quantity column, we use one row per sellable unit. An item with 10 units has 10 rows.> But one row per unit for all inventory would break down at scale—an item with 50,000 units across 10 locations would mean 500,000 rows, and the reserve query would slow as it scans through them. Instead, we maintain a bounded…
-
It seems there could be a simpler solution.1. Deduct the reservation from the inventory when the user starts to order, but in the same txn also maintain a separate row for the in progress order flow. 2. If the order flow is aborted or times out have a background process that returns these to the inventory.That seems simpler than this approach and…
-
not the best design to have 1000 rows for each shop*SKU combination. If a candidate proposed this solution during Shopify's System Design interview, i doubt he would be vetted for Senior+ position.Instead of having 1000 rows per shop*SKU, why not just have one row per shopping cart*SKU?That way a single row would represent a single cart, and will…
-
My main takeaway from this post is that in 2026 we haven't developed enough technology to scalably and durably handle concurrently decrementing a single number. This has caused multiple organizations to develop database hacks (the multiple rows) or complex architectural solutions (redis) which destroy the atomicity of the process.
-
Could not they shard the inventory table by shop_id? As I understand, the order includes only items from one store, so there is no need to keep all the stores in a single table.Also, I wonder why they could not have a row status (available/reserved) and UPDATE it instead of deleting the rows.
-
Mostly unrelated but shopify is incredibly annoying. They introduced this delivery tracking app called "shop" and it has become unavoidable when buying electronics from china. Recently looked at it with mitmproxy and it ships home more than gets shipped to me.
-
Why even have a blog when you can't be arsed to write the posts. This is so obviously LLM-written. I have a positive view of Shopify engineers, but this kind of made a dent in that confidence.
-
The high contrast dark theme made my eyes squint and I started getting a headache within 60 seconds of trying to read the page. The war on light themes needs to end.
-
I don’t get Why AI written technical article is a big thing here. Did we care if an article is typed or handwritten at a point?