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.
We replaced Redis with MySQL for inventory reservations and it scaled
131–140 of 282 posts
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#132[flagged]
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#133I 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.
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#134> 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…
Maybe the example numbers are just bad - but now you expect your system to fall down if you scale from 10 to 100 locations?
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#135Earlier quoted context omitted.
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.
Don't get shy now. Which slurs?
Let's say some racial ones (including hard-r n-word) and some ableist ones? Guy also talked about jerking off a lot and joked about rape.
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#136> 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…
Maybe the example numbers are just bad - but now you expect your system to fall down if you scale from 10 to 100 locations?
"Number of locations" is an input so if the system has been designed to handle up to 10, and not 100, then yes I would absolutely expect it to fail with the higher value.
Developers (and everyone else really) need to think about systems, with the system taking inputs like "number of locations", and producing outputs like "available inventory", and when the input parameters change outside of the designed scope, without the system itself changing, then you should expect things to break.
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#137Earlier quoted context omitted.
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.
replenishment is an unnecessary cludge that only exists due to poor design. an "algorithmical smell" if you wish
[dead]
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#138Mostly 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.
Mood. It's not just over-seas. With a domestic courier they still use dark-ui to hide the tracker link via "shop".
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#139I 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.
[dead]
Re: We replaced Redis with MySQL for inventory reservations and it scaled
#140"But the hardest lesson wasn't about database design. It was discovering that the real bottleneck wasn’t what we were observing and measuring."
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.
[dead]