Live data from Hacker News

We replaced Redis with MySQL for inventory reservations and it scaled

shopify.engineering

71–80 of 281 posts

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

#72
post #12
post #7

so this is interesting to me, im in retail i work closely with platforms ive used shopify ive used magento ive used smaller players ive helped implement various pieces of all of them. and i was excited to get some insight, then i realized that this whole thing was written by AI and im going to guess the idea and implementation were probably very AI driven. > The solution: SKIP LOCKED > Core idea: one row per unit, bo…

I found Shopify’s post very easy to read, and learned about some features of MySQL. On the other hand, I didn’t get any value from reading your comment. You seem to have a bunch of opinions about how things should be done, but haven’t given any details about how you came to these conclusions.

I found it really hard to read, the llm-isms are just too distracting. Does no one proof blog posts anymore?

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

#73

Shopify’s founder and their coo both fund far-right extremism, and its founder thinks only rich people should be able to vote. But anyway, they switched databases. https://www.techwontsave.us/episode/340_shopifys_leaders_are...

The link you shared is just a podcast and does not contain even contain “far right”. Can you provide specific concerns, otherwise I don’t see anything wrong with a CEO of the most successful tech company should not be concerned about a horribly performing country from a GDP perspective.

You should be concerned what they spot as the problem and what they propose as the solution

https://www.ctvnews.ca/business/article/shopify-ceo-draws-cr...

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

#74

Earlier quoted context omitted.

I don’t understand how this should prevent oversold. You have a check that reports empty or oversold inventory. But how does that check prevent 2 concurrent actors fighting for the last item from inserting 2 rows?

how does current design resolve concurrent actors fighting for the last item ? there is ultimately needs to be some global mechanism resolving this conflict. Currently it is an order in which db engine processes transactions by locking rows for a transaction, whoever got the first lock, wins the last remaining items. my design is the same, except it does not need this dance with moving rows between tables, locking th…

> how does current design resolve concurrent actors fighting for the last item ?

It resolves with skip locked. Assuming we have only 1 item left. First query scans the buffer table, locks as many rows as needed (1 in our case), and moves rows to another table. Second query scans the table, finds no rows (even if first one hasn’t finished yet, the row is locked and ignored), checks if it can increase buffer, finds out that it’s fully sold and aborts. Db guarantees that you can’t oversold.

> my design is the same, except it does not need this dance with moving rows between tables, locking them, and the cludge with replenishment process.

I can’t evaluate whether it’s the same or not, because you still haven’t clarified when exactly you’re going to insert the row. In the article they’re inserting in the same transaction. Would you also do it in the transaction? Because if you’ll introduce a separate global mechanism to resolve conflicts, on a high level it would be the same as their approach with redis (you need to have 2 systems)

EDIT: wording

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

#75

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 hold info of multiple items of the same SKU. No need a cludge with 10…

I have never worked anywhere where describing how their system actually works would pass the company's own system design interview

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

#76
post #28

They were really so proud of that AI image that they just had to tack it on at the end? Did nothing but make the blog post feel like cheap mass produced slop

This is Shopify, the leadership is full steam ahead on AI in a big way and they review employee performance based on AI usage.

And Lutke is a fascist.

All the biggest proponents of AI seem to be fascists.

Weird.

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

#77
post #50

Earlier quoted context omitted.

Why are you trying to get someone to repeat slurs?

Because "slurs" is vague and covers a wide variety of utterances that run the gamut from unprofessional to unemployable and I had a tingle of Spidey sense that OP might have chosen the vague phrasing specifically to inflate the sins of the nameless Shopify director in the mind of the reader.

I... guess that's possible? Summarization doesn't really seem suspicious to me.

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

#78

Earlier quoted context omitted.

Because "slurs" is vague and covers a wide variety of utterances that run the gamut from unprofessional to unemployable and I had a tingle of Spidey sense that OP might have chosen the vague phrasing specifically to inflate the sins of the nameless Shopify director in the mind of the reader.

Which slurs are ok, and which aren't?

Great question. It's a vague term and a moving target that not everyone agrees on.

For instance, retarded is now considered a slur. If OP is saying "my director said the R word," then I would question whether OP spared the gory details out of concern for polite company or if they're being oblique in service of their point.

And if managers at Shopify are dropping N-bombs, I want to know that too.

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

#79

Earlier quoted context omitted.

I don’t understand how this should prevent oversold. You have a check that reports empty or oversold inventory. But how does that check prevent 2 concurrent actors fighting for the last item from inserting 2 rows?

how does current design resolve concurrent actors fighting for the last item ? there is ultimately needs to be some global mechanism resolving this conflict. Currently it is an order in which db engine processes transactions by locking rows for a transaction, whoever got the first lock, wins the last remaining items. my design is the same, except it does not need this dance with moving rows between tables, locking th…

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 is a bit weird. I'd want to commit the reservation transaction with inventory decrement along with a payment key and then use a different transaction to drop the reservation when the transaction completes. If the transaction does not complete in a timely manner you probably need to query external systems anyway to resolve whether the payment actually occurred or not.

They talk about lock contention in this case, but I also wonder about latch contention since these rows are adjacent. If it's a small transaction that's not interactive, does mysql resolve it with just the latches on the needed tables?

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

#80
post #73

Earlier quoted context omitted.

The link you shared is just a podcast and does not contain even contain “far right”. Can you provide specific concerns, otherwise I don’t see anything wrong with a CEO of the most successful tech company should not be concerned about a horribly performing country from a GDP perspective.

You should be concerned what they spot as the problem and what they propose as the solution https://www.ctvnews.ca/business/article/shopify-ceo-draws-cr...

The problem he was reacting to (local decisions dominated by people with locked-in benefits and low future exposure) is real. His idea there is silly but I think treating a couple of provocative X replies as some far right agenda is its own kind of overreach.
Post reply on HN