We replaced Redis with MySQL for inventory reservations and it scaled • Hacker News Board

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#241

Post by zer00eyz » Sun, Aug 09, 2026, 6:34 PM UTC

bijowo1676 wrote: post #200

zer00eyz wrote: post #170

Earlier quoted context omitted.

Your mental model here is mapping too close to an actual cart in a retail, at a in person, setting. The assumption that a SKU maps 1 to 1 to a cart item is flawed. If the first item in the cart is a bundle of SKU-A and SKU-B, the second item is a bundle of SKU-A and SKU-C and the third item is 5xSKU-B where do you do you keep the re-agregation of the SKU-X's to track them? This is without accounting for item location…

Modeling after physical shopping process is actually the proper way to design a eshop system. Imagine you are at Walmart store and go to checkout stage, you would have to pick item from the shelf and take it from availability for other shoppers, before you pay for the item. What shopify did, is customer enters the store, heads straight to checkout and retail workers races back to shelves to pick up items for client.…

If Walmart (in person) behaved like Walmart (on line) the isles would be so littered with half full carts and items that others could not buy you would be unable to move in the store.

https://baymard.com/lists/cart-abandonment-rate

70 percent of carts are abandoned. You dont want your inventory sitting in carts, when other people want to buy it. It only comes off the shelf (and gets put in a box) when you have money in your hand.

There is an entire ecosystem around Shopify to reach out to abandon cart holders and attempt to convert them: https://apps.shopify.com/categories/marketing-and-conversion...

> Sometimes it says: sorry bud, item is sold out, frustrating customer experience, who is already mentally prepared to pay and own an item.

This is better than A) taking their money and then telling them you dont have it. B) Them not being able to buy it because someone has it in their cart and is NEVER going to check out with it.

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#242

Post by derangedHorse » Sun, Aug 09, 2026, 6:39 PM UTC

samudrijan wrote: post #203

energy123 wrote: post #165

Earlier quoted context omitted.

Subheading and dot point spam, low density writing (the opposite of standard technical english), including useless detail (like enumerating stats on Shopify's scale), using contrastive parallelism, and other llm-isms. Even if it's not AI it's bad writing done by someone who has picked up AI's worst ticks. For example this subheading: > "The real bottleneck: connections, not CPU" That's two AI smells. AI likes to say…

Say the thing, not contrastive parallelism. Thanks for putting a name to that horrible LLM habit.

Binary opposition is another name for it: https://en.wikipedia.org/wiki/Binary_opposition

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#243

Post by derangedHorse » Sun, Aug 09, 2026, 6:45 PM UTC

watrr wrote: post #218

cataphract wrote: post #216

Earlier quoted context omitted.

In every AI-written post, we have the script: some top post complaining it's AI-written, someone cluelessly saying they don't see it, and another person pointing out the claudisms. Sometimes someone posts a link to pangram. I think we need the moderation team to set up some policy. In which direction idk.

The EU helps. We can report Spotify for not labeling this content, since a substantial number here think this obviously AI assisted post is genuine: https://www.theguardian.com/technology/2026/jul/31/ai-labels... Spotify's defense will then be that this post is obviously AI assisted garbage.

Shopify*

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#244

Post by derangedHorse » Sun, Aug 09, 2026, 6:47 PM UTC

dessimus wrote: post #227

resonious wrote: post #171

Earlier quoted context omitted.

I work with Shopify often and the whole oversell protection thing is like a huge joke. Oversell happens because Shopify doesn't decrement inventory until payment is confirmed. And they apparently would rather die than change that invariant.

Would a retail business want the inventory to decrement just because users put items into carts that get abandoned? Seems like that would really mess things up more in the long run.

An unconfirmed payment might also refer to a credit card charge that is 99% guaranteed to go through but hasn’t completed yet

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#245

Post by ChrisMarshallNY » Sun, Aug 09, 2026, 6:52 PM UTC

Induane wrote: post #238

ChrisMarshallNY wrote: post #189

Earlier quoted context omitted.

Well, one thing to remember: AI learned from us (See what I did, there?) . The training these LLMs got, was from endless human-slop, on sites like LinkedIn, and marketing copy, everywhere. In fact, don't be surprised, if we start learning from AI; reversing the process. But I think that it's only a matter of time, before almost everything will be at least touched by AI. I posted this, yesterday[0]. It wasn't a partic…

I read your linked comment and I'm bummed out because I agree. The thing is that I LIKE writing code. It's fun. I don't LIKE coding with an LLM. It isn't fun. We can't go back to a place where the professional code is all hand written. But at the same time I'm sad and tired. The joy has been utterly sapped and I don't think I'll be able to do this as a career for much longer.

Well, I am sorry to hear that, but it hasn’t been my experience.

That may have something to do with the way that I use an LLM.

I use it as a “pair partner,” not as an agent.

Most of the code in my apps is mine, but I do ask the LLM to take care of some of the “overhead” tasks, such as minor utility functions.

In fact, I just got done, ripping out a bunch of code the LLM wrote, in my current app, and replacing it with my own work. It seems that I can’t really ask the LLM to do much beyond function level, without it going sideways.

I simply can’t understand people shipping entire, vibe-coded apps. If I let the LLM write my whole app, it would be hot garbage.

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#246

Post by solatic » Sun, Aug 09, 2026, 6:59 PM UTC

manbash wrote: post #8

> 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 pool of available rows, capped at 1,000 per item/location combination…

Yeah, I'd be uncomfortable with that approach. One of their key design goals was to minimize underselling, recognizing that it results in lost revenue. But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeeds?

I'm skeptical of this approach. Sure, row contention means that you cannot have a database transaction per customer order attempting to decrease inventory count by 1 each time. But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely). Attempted customer orders are submitted to a reservation system put in charge of assembling the batches. Customers wait some short period of time - say, 15 seconds - for the reservation attempt to be batched and to be notified that they successfully locked a reservation. Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#247

Post by jamilbk » Sun, Aug 09, 2026, 7:23 PM UTC

sharno wrote: post #229

I think this could have used tigerbeetle instead?

I came here to make a similar comment. It seems like TigerBeetle was built for exactly the type of transactional processing this post is about?

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#248

Post by cindyllm » Sun, Aug 09, 2026, 7:38 PM UTC

ChrisMarshallNY wrote: post #245

Induane wrote: post #238

Earlier quoted context omitted.

I read your linked comment and I'm bummed out because I agree. The thing is that I LIKE writing code. It's fun. I don't LIKE coding with an LLM. It isn't fun. We can't go back to a place where the professional code is all hand written. But at the same time I'm sad and tired. The joy has been utterly sapped and I don't think I'll be able to do this as a career for much longer.

Well, I am sorry to hear that, but it hasn’t been my experience. That may have something to do with the way that I use an LLM. I use it as a “pair partner,” not as an agent. Most of the code in my apps is mine, but I do ask the LLM to take care of some of the “overhead” tasks, such as minor utility functions. In fact, I just got done, ripping out a bunch of code the LLM wrote, in my current app, and replacing it with…

[dead]

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#249

Post by jorangreef » Sun, Aug 09, 2026, 7:45 PM UTC

neerajsi wrote: post #114

neerajsi wrote: post #79

Earlier quoted context omitted.

Clearly this is for high concurrency cases where there are many people racing to get all the available items. It's not clear that it's in shopifys or the sellers interest to let items get sequestered in people's shopping carts, which is a spot where there isn't a strong commitment to complete the purchase. At payment time, you can be more assured that the item will actually be purchased. Still I think their solution…

I was curious about what Tiger Beetle does. It has two phase transfers, which appears tailor built to handle this case. But maybe Tiger Beetle isn't the right database to track all your product stocks.

TB was designed to track stock inventories (as another form of double-entry accounting).

Re: We replaced Redis with MySQL for inventory reservations and it scaled

#250

Post by soontimes » Sun, Aug 09, 2026, 8:03 PM UTC

solatic wrote: post #246

manbash wrote: post #8

> 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 pool of available rows, capped at 1,000 per item/location combination…

Yeah, I'd be uncomfortable with that approach. One of their key design goals was to minimize underselling, recognizing that it results in lost revenue. But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeed…

> But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeeds?

They explicitly cover this in the article, saying they do reservation inline. It does increase latency for these orders, but it doesn’t result in an error

> But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely).

They mention this as well, checkout batching increased implementation complexity.

> Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.

True. The article would’ve been better if they included such numbers. However the fact that they didn’t mention this doesn’t imply they haven’t done research. I haven’t found anything related to checkout specifically, however there are in general articles, indicating that increased latency correlates with revenue drop.