Many architecture discussions start with choosing the right database, and we recently went through a similar decision in our own project, where our understanding of the data model made a strong case for a distributed database and a master-node architecture; the expected access and partitioning patterns did not materialize as the system evolved, so we eventually moved to a non-distributed database to simplify the landscape and remove distribution costs that were no longer giving us enough value. Shopify’s inventory reservation migration is a reminder that a useful question would be if the whole transaction path is understood well enough to identify the actual constraint.
Shopify moved inventory reservations from Redis into MySQL so reservations and the inventory ledger could participate in the same ACID transaction, which removed a class of consistency problems created by coordinating state across two systems.
The interesting part is what happened after the database design worked; throughput still hit a ceiling, query latency remained acceptable, and CPU was not saturated, so the team instrumented connection usage by business process and found that other checkout work was holding connections longer than expected. After reducing reads and transactions on the primary database, and revisiting an old InnoDB concurrency setting, the system moved past the previous limit, which reinforces a point that applies well beyond MySQL: bottlenecks often appear at the boundary between components, not inside the component receiving the most attention.
I will remember this in my future architecture reviews. When the numbers do not agree with the current diagnosis, expand the observability boundary before settle on a conclusion.
https://shopify.engineering/scaling-inventory-reservations