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 writing aids? Using AI does not mean no human effort was involved.

unfortunately its new normal now

I agree with you, it doesn't take long to identify the itemized style that LLMs use and it's always incredibly annoying.

I would rather read the original thoughts of the engineer, grammar mistakes and stylistic imperfections included, than prompt generated AI slop.

I just wanted to drop a note that I almost never go into an article or blog wondering if its AI or not. I am trying to be a more picky reader and try to actually do something occasionally but I do browse database articles and this is a good one. So I wonder, am I becoming insensitive about AI writing? Am I being hypnotized into taking whatever color pill thats had a color representing a surrender to the AI "hive mind" whatever that is?

So I'm sort of curious, did you not like the AI writing style or just rejecting AI in general? I myself am very conflicted, I think AI in its current form is the wrong tech at the wrong time yet I don't mind reading AI text and sort of mooch off of googles free tier.

Also I'm starting to notice lots of AI smearing, I read folks online describing someone elses contribution as "obviously AI" and I'm suspecting in some cases these could be false accusations.

I'm thinking about starting a blog, so when my AI gf writes posts, do I ask her to try to "not read like an AI"? Anybody try that? I'm gonna try that. Hehe for all you know I already did hehe

Mood. It's not just over-seas. With a domestic courier they still use dark-ui to hide the tracker link via "shop".

I agree, it does seem awfully complicated and there are quite a few pieces missing for this to be a complete solution.

I'm a bit surprised about the scalability case against a simpler solution. This is not about Shopify's scale. We're talking about contention for a specific SKU of a specific seller at a specific warehouse location.

How many shopping carts are competing for a single SKU at the payment stage at peak hours? Can this really be too much lock contention for a single database row?

I realise Shopify engineers are neither stupid nor inexperienced. Hence my surprise. I would have liked to hear more about that specific problem.

I would call this one-row-per-contract-type, and this is the most general model for the problem (e.g. the model cannot be further broken down into finer level), thus, the most scalable model given storage is dirt cheap.

Comes down to type of items, when you have physical inventory the number is limited so more manageable and interestingly enough the problem only applies to physical inventory.

You are just spending some more disk space to avoid synchronization issues. Denormalization for performance is a really common pattern, just that people do not start with it in the first place itself

> an item with 50,000 units across 10 locations would mean 500,000 rows

I don't get it, Wouldn't that still only be 50,000 rows, just divided across locations?

Maybe the example numbers are just bad - but now you expect your system to fall down if you scale from 10 to 100 locations?

you should, their design is not the best. There is middle ground between "one row per SKU" and "1000 rows per SKU".

Its called one row per shopping cart*SKU combo.

if two people order 100 and 500 items of the same SKU, respectively, the table should have only two rows: for order1 and order2. Not 600 rows.

I guess it depends on how the replenishment process works. Unless you're ordering over 1000 of an item, I doubt it would be a problem.

Depends on the scale. Most companies don't approach the scale where this matters.

I'm familiar with the reserved row approach (I use SELECT FOR UPDATE SKIP LOCKED) and yeah this replenishing idea terrifies me.

My understanding is: your proposal is not very different from what Shopify is doing except they are tracking 'reserved units' (one per row) and you are proposing tracking 'orders' as the temporary state to then reconcile back with inventory quantities.

The moment you added a background process you just replaced the complexity.

1. Backgrounds process can back up

2. They need context of the user and need to switch context per user

3. What if they fail, you create some DLQ or another process to handle the failure

4. Who looks on those failure and how do they act

TLDR; there is always a cost

Can you clarify why this involves no locking? There can still be 2 actors fighting for the same row.

now you have two problems. what happens when your reservation system backs up?

I was investigating Durable Objects (DO) and had Fable walk me through where in my app they might be appropriate. One place had a dependency with billing (where I use a transaction now) and the proposed re-work to allow for concurrent editing with DO looked very much like this, reservations with idempotency keys. And if you add hierarchical allotments then it scales pretty well.

I disagree with the other posters about the bg process, if you have any bg processing already you should be able to handle the few edge cases without too much trouble.

Even the good teams may make bad choices, that's why it is interesting to read their ideas and discuss them

They never said they don’t shard it, however this doesn’t solve the problem they were facing. Even if they have a single store (therefore a single shard), the burst demand may be high for the item in that shop, which creates contention for “remaining item quantity” resource. Their solution spreads this contention across several rows.

> Also, I wonder why they could not have a row status (available/reserved) and UPDATE it instead of deleting the rows.

This requires a row per item unit, doesn’t it? If you have 50k units you’ll have to track status of every item, meaning 50k rows. They also mention this as a rationale to use at most 1k rows, and treat it as a buffer.

> not the best design [...]

So those engineers at Shopify worked hard for months on a more performant system, but they missed the obvious structure? They chose a complex denormalization for no good reason?

It may be true, but I think it's presumptuous to belittle their work when we have only partial information. My guess is that they had good reasons to think that the more obvious ways would not scale.

And from reading your comments in this thread, I believe your structure would fail at their scale. A SQL query that uses 2 sub-queries with "group by" is probably too heavy. From the post, at peaks there would be millions of active shopping carts.

BTW, I suspect most orders are just for 1 or 2 of each item, so the denormalization is not as heavy as it seems.

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

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 in the reservation - and rules that may apply around that.

You haven't even gotten to the part where different customers will have different rules around shipping from different locations - because that can eat into margins.

You're also making a bunch of other assumptions around transaction flow and where carts are actually stored (and how they get converted to an invoice, with payment attached) that likely do not hold true.

Could you do it more like what you're sugesting -- maybe -- but only in a single tenant system.

Others are almost never as dumb as you hoped, and you’re rarely ever as smart as you think.

> Instead of having 1000 rows per shopSKU, why not just have one row per shopping cartSKU?

At what point that row is inserted?

And that's why these interviews can be stupid, you can mention the real solution and interviewers might reject because it's not the textbook solution

But the real world is different

But was it load bearing?

It's honestly weird Claude converges on this language because it's incredibly wordy and hard to parse.

One would think semantic density would win out in training.

Most likely? Time.

Using off the shelf software means you mostly design how to plumb things together and how to make them correct , safe and scalable.

The things you mention, on the other hand, carry the same requirements but are also much complex to develop AND to maintain.

What way would that be?

Redis doesn't have transactions and persistence.

No persistence means the data gets lost if machine shuts down or process crashes. Furthermore, after restart you will need to regenerate the data which can take time. That's why Redis is a cache and not a database. You can fix the persistence issue (Redis can write WAL log, don't remember if it does fsync or not), but then Redis won't be able to handle those thousands of concurrent connections.

Redis (and other NoSQL storages) don't have some magic architecture that gives them advantages over SQL databases. They just cut corners on ACID guarantees and skip fsync. Once you start doing fsync, your transaction throughput will drop to SQL database level.

Redis also doesn't have transactions which means every app error damages the data. You will spend engineer hours investigating and fixing the problems. Transactions save so much time and worries.

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

The blog probably was.shopify was pretty early and publicly all in on using AI for everything

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.

Yeah it's an awful place to work unless you're a far-right bro. My old director used to use slurs and vape in the office. The founder hires pro gamers with no technical expertise because he thinks they're cool.

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.

You should be able to do these increments/decrements in a database at the rate you can write WAL to the disk. But the problem is in a lot of these databases the transaction will hold locks until the WAL hits the disk which causes a massive serialisation problem when you have lots of writes to the same row.

For example if it takes 20ms to write a batch to the WAL then if you do 5 updates to the same row then that is a minimum of 100ms. But without waiting on locks if you can batch all the WAL writes together then this could be just 20ms.

I don’t think holding locks while waiting for WAL is strictly necessary. There is definitely some anomalies that can happen if you don’t wait for WAL to be durable because transactions that don’t write WAL can observe non-durable writes in some situations. So for example conditional updates that don’t perform work. But I assume this can be fixed by making these wait on the commit for dependent transactions to become durable if they are empty. There is also the problem of failing writes that reveal information about non-durable writes which is more tricky. For example you try to insert into a unique index and it fails, but the duplicate was due to a non-durable write that is lost.

Pure reads should be fine when using MVCC because you just show the latest durable version of the DB. I know some other replication systems will run all transactions including reads through the WAL/replicated log in order to not have anomalies.

They do heavily use AI, but you haven’t refuted their point that if inventory is in SQL, storing reservation in a second storage system increases complexity.

Example of their culture: https://x.com/tobi/status/1909251946235437514

Most companies would be best served picking MySQL or PG and only adding something else if absolutely necessary. Every piece of software added increases complexity.

It can be easier and cheaper to solve problems via technology changes than operations and people

Now you only need MySQL expertise and maintenance rather than Redis and MySQL

The default should be that every additional piece needs to be justified