Shopify ditched Redis for MySQL and it worked
Shopify published a post explaining how they replaced Redis with MySQL for inventory reservations at scale. The punchline from the thread is the quote: 'the hardest lesson wasn't about database design. It was discovering that the real bottleneck wasn't what we were observing and measuring.' A retail industry commenter jumped in to say they were excited to dig into the details and see how it applied to their own stack.
The pattern here is a recurring one on HN: a widely held infrastructure assumption (Redis is the right tool for high-throughput reservation-style workloads) gets publicly overturned by someone running at real scale. MySQL, a technology most people treat as boring and solved, handled it. The lesson is not 'use MySQL instead of Redis' but 'measure the actual bottleneck before assuming the conventional stack is right.'
This threads through several recent HN discussions about over-engineered stacks. The instinct to reach for a specialized tool (Redis, Kafka, etc.) often precedes the evidence that a simpler tool would not work.
So what?
Before adding a new data store to your stack, actually measure whether your current one is the bottleneck. Shopify's post is a concrete example of a company saving operational complexity by going simpler, not more sophisticated. Reducing your number of moving parts has real reliability and hiring benefits.