We replaced Redis with MySQL for inventory reservations — and it scaled

[-]

daltorak@reddit

SQL Server graybeards nodding their heads sagely at all the READ UNCOMMITTED (aka NOLOCK) statements that have provided 25 years of job security. 👍

[-]

Dextro_PT@reddit

So they replaced a KV store with another KV store? :P

I kid I kid. The real insight here is a bit further down the list:

The previous system stored reservations in Redis. Each item had a quantity key, and reserving meant DECR, releasing meant INCR. Redis handled concurrency fine, but reservations and the inventory ledger lived in two different systems.

(emphasis mine)

So, once again, the big headline about "Technology X over Y" is, in fact, a question about moving to the correct architecture and the technology is kind of secondary. They used MySQL because they already used MySQL for part of the data.

[-]

tooclosetocall82@reddit

It’s towards the bottom but this is the main takeaway:

“Revisit old decisions”

MySQL wasn’t always the right architecture for this use case for them, now it is.

[-]

Jiuholar@reddit

Why isn't that just the title then??

[-]

dkarlovi@reddit

Would you click that?

[-]

shaving_minion@reddit

if their target audience is software engineers, yes gladly

[-]

efvie@reddit

This is a pretty straightforward design; I think the neatest insight is the capped reservable inventory that’s managed separately.

[-]

Rustywolf@reddit

Is /dev/null web scale?

[-]

sisyphus@reddit

Well it's O(1) for every db operation: https://github.com/dcramer/mangodb so yes I would say so.

[-]

rysto32@reddit

You'll enjoy the same reliability as you're used to with MongoDB

Brutal

[-]

OMG_A_CUPCAKE@reddit

Yes

[-]

AmoebaDue6638@reddit

Shopify proving once again that the boring technology wins. MySQL with proper indexing and row-level locking handles way more than people give it credit for, especially when you eliminate the network hop to a separate cache layer.

[-]

tooclosetocall82@reddit

If you read it’s only possible because of a new MySQL 8 feature. Old technology that’s being actively modernized wins.

[-]

Murky-Relation481@reddit

I feel like this was accomplishable even before that feature. Holding inventory for a few minutes while people move through a checkout flow is not exactly new tech and this feels more like a design decision where they wanted to keep all of that logic in the database at all times rather than creating a running ledger that gets synced back (which is whatni assume they were doing with redis, but could have been done with older versions of MySQL as well).

[-]

tooclosetocall82@reddit

Accomplishable, sure. Accomplishable at scale? Maybe not. The key for them was SKIP LOCKED which was only recently added to MySQL. They noted the other solution had potential race conditions that this solution avoids, but the performance of Redis was worth the risk since MySQL presumably cousins handle it at the time.

[-]

txmail@reddit

I mean... it really is just a different lock pattern. It could have been done in Redis but they simplified and got atomic at the same time.

[-]

KandevDev@reddit

the actual move is 'we replaced eventual-consistency with row-level locking'. SKIP LOCKED is the underlying primitive that makes MySQL viable here, and it has been in postgres for a decade and innodb since 8.0. the pattern works in any DB that supports it, the Redis-vs-MySQL framing is a bit of a misdirection.

[-]