Shopify перевела резервирование товаров с Redis на MySQL¶
7.0/10
Shopify описала, как заменила Redis на MySQL в системе резервирования инвентаря, чтобы сделать процесс более надёжным и масштабируемым. Вместо одной строки с количеством товарных единиц используется модель «одна строка на продаваемую единицу», но для ограничения нагрузки применяется пул не более 1000 доступных строк на сочетание товара и локации. Резервирование потребляет строки из этого пула, а отдельный процесс пополнения восстанавливает доступные строки по мере необходимости. Такой подход позволяет избежать сканирования сотен тысяч строк при крупных остатках и сохраняет работоспособность запросов резервирования на масштабе.
Контекст¶
Инвентарные резервирования нужны, чтобы на этапе оформления заказа временно удерживать доступные товарные единицы и не допускать продажи отсутствующего остатка. Redis часто используют для таких быстрых временных состояний, но реляционная база данных, например MySQL, может обеспечить транзакционную целостность и более простые гарантии согласованности при высокой нагрузке. В статье Shopify от 12 мая 2026 года описывается переход на MySQL с использованием SKIP LOCKED, составных первичных ключей и ограниченного пула строк для масштабирования.
Влияние¶
Для инженеров по высоконагруженным системам это конкретный пример того, как реляционная база данных может заменить Redis в сценариях инвентарных резервов при правильном моделировании строк и ограничении рабочих наборов.
Обсуждение¶
Комментаторы обсуждают техническую схему, предлагая альтернативы через durable workflows или отдельные строки для незавершённых заказов, но часть критики касается качества текста и предположения о LLM-генерации поста. Также звучат претензии к навязчивости приложения Shop для отслеживания доставки, не связанные напрямую с архитектурой.
Детали¶
Ключевая проблема модели «одна строка на единицу» заключается в том, что при 50 000 единиц товара в 10 локациях получилось бы 500 000 строк, и запрос резервирования деградировал бы при сканировании. Shopify решает это bounded pool: на каждую пару товар/локация хранится не более 1000 доступных строк, а резервирование берёт строки только из этого пула. Когда пул истощается, replenishment-процесс подготавливает новые доступные строки из фактического инвентаря. Это превращает потенциально тяжёлую операцию в работу с ограниченным набором строк, сохраняя семантику поштучного резервирования без необходимости держать все единицы в горячем наборе MySQL.