Live data from Hacker News

We replaced Redis with MySQL for inventory reservations and it scaled

shopify.engineering

191–200 of 281 posts

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

#191
post #133

I never spent much time with the whole NoSQL movement, it always seemed something out of people that don't get how to optimise SQL queries, or suffer from SQL allergy, only to reinvent it badly in custom languages.

There are many good reasons to use NoSQL instead of a "full SQL database". OTOH I can relate to your experience, I remember colleagues switching to MongoDB because they couldn't get good performance on the (MS) SQL database. They didn't know enough about proper (multi-column) indexes, use proper isolation levels, etc.

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

#192
post #159

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.

What exactly makes it "obvious" that this is written by AI? I could totally believe that AI was used to generate parts of it, but I really don't get the sense that the whole thing was written that way. I've seen way worse examples on this site. As software engineers we are constantly told that we need to heavily use these tools for our daily work. So is it surprising that software engineers use the same tools as writ…

"No waiting on the same row, less contention."

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

#193

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.

I think they're just following the orders of the CEO.

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

#194
post #190

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…

[flagged]

> But enjoy your intellectual wheelchair, which for some reason you feel the need to advertise after 40 years of programming. I'm sure it is just in the best interest of future generations ...

I love this place. We are such class acts.

Have a great day!

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

#195

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.

That and they helpfully share your email with a company if you add something to your cart. You don't even have to checkout or submit a form or anything. I can't tell you the number of spam emails I've gotten from companies because they auto add everything they get from shopify to their mailing list and then nag you about not checking out

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

#196

Earlier quoted context omitted.

There were woot offs 20 years ago. Flash sales are not some new scaling issue.

Its also not a solved one considering basically no platforms support them.

It's not? Shopify does it, woot does it, amazon does it, yes style does it, royal Caribbean does it.

Seems like a lot of places can do it for it not to be a solved problem.

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

#197

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…

I really wish that slop writing was disincentivized in whatever RLHF they do. I don’t want to read the weird LinkedIn pop-sci tone for the rest of my life in such amounts. I wonder if the average reader is also getting annoyed like this or whether they just don’t care - especially seeing what seems to get upvoted on your run of the mill social media sites. They probably collectively shape things more than I do.

I wish they don’t stop. Make it easier to skip past.

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

#198

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.

I agree, I too found this barely readable.

Interestingly, ChatGPT was able to parse and explain it to me. I got a lot out of its presentation.

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

#199

Earlier quoted context omitted.

Most payment methods in the world don't support separate authorization and capture.

i dont know about the world, by authorize.net and Stripe, which work globally and work with global credit cards, they do support separate authorize and separate capture, which seems to be part of PCI standard https://docs.stripe.com/payments/place-a-hold-on-a-payment-m... https://support.authorize.net/knowledgebase/Knowledgearticle...

[deleted]

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

#200

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…

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. Sometimes it says: sorry bud, item is sold out, frustrating customer experience, who is already mentally prepared to pay and own an item.

Re SKU storage, you will have multiple row entries per SKU, if I order two items, there will be two rows corresponding to the items in your Purchase order.

The sum() aggregation check will run across all active orders per sku

Re single tenant: shopify creates 1000 rows per SKU per shop(tenant!!). As long as tenant is on the same DB you can run it, just add shop_id to the group by field

Post reply on HN