Shopify рассказала, как отказалась от Redis в одной из самых критичных частей своей платформы — системе защиты от перепродажи, которая отвечает за резервирование товаров во время оплаты.
Компания перевела механизм на MySQL и смогла выдержать пиковые нагрузки Черной пятницы 2025 года, когда магазины на платформе продавали товаров на $5,1 млн в минуту.
Речь идет о коротком резервировании товара между нажатием кнопки «Оплатить» и завершением платежа. Если система ошибается, возникают две проблемы: либо один и тот же последний товар покупают сразу несколько человек, либо покупателю показывают «нет в наличии», хотя товар еще есть.
Для Shopify обе ошибки дорого обходятся продавцам.
Почему Redis перестал устраивать Shopify
Старая схема работала через Redis: количество товара хранилось в виде счетчика, а резервирование происходило через DECR. Это было быстро, но создавало архитектурную проблему — сами остатки лежали в MySQL, а резервирование в Redis.
Из-за этого операции нельзя было объединить в одну ACID-транзакцию. В некоторых сценариях система могла списать товар в базе, но не убрать резерв в Redis. Или наоборот.
Плюс Redis-схема плохо подходила для работы с несколькими складами и требовала поддержки отдельного кластера.
Как Shopify решила проблему
Вместо хранения количества товара в одной строке, Shopify перешла к модели «одна единица товара = одна строка». Если на складе 10 товаров — создаются 10 строк. Резервирование просто забирает нужное число строк через SELECT ... FOR UPDATE SKIP LOCKED.
Ключевым здесь стал механизм SKIP LOCKED из MySQL 8. Он позволяет пропускать уже заблокированные строки вместо ожидания освобождения блокировки. То есть параллельные заказы не упираются в одну и ту же блокировку.
При этом Shopify не хранит бесконечное количество строк. Для каждого товара действует лимит — максимум 1000 строк резерва на комбинацию «товар + склад». Если пул заканчивается во время флеш-распродажи, система автоматически пополняет его из основного журнала учета запасов.
Настоящая проблема оказалась не в MySQL
Самое интересное началось уже после запуска. Команда долго оптимизировала блокировки, индексы и SQL-запросы, но производительность все равно упиралась в потолок.
Оказалось, проблема вообще не в MySQL-запросах. Бутылочным горлышком стали подключения к базе.
Разработчики обнаружили, что другие части системы проверки слишком долго держали открытые соединения с MySQL. В результате система резервирования просто добивала уже перегруженный пул соединений.
Чтобы найти проблему, Shopify начала помечать SQL-запросы тегами вроде /* conn_tag:checkout_completion */, а затем анализировала, какие бизнес-процессы дольше всего удерживают подключения через ProxySQL.
После оптимизации checkout-пайплайна, компания сократила число чтений с основной базы на 50%, а количество транзакций — на 33%.
Redis отключили постепенно
Полного «переключателя» не было. Shopify несколько месяцев держала Redis и MySQL одновременно в shadow mode: обе системы получали одинаковые запросы резервирования, но источником истины оставался Redis.
Только после проверки корректности и нагрузки Shopify постепенно перевела продакшн на MySQL — начиная с менее загруженных подов и заканчивая крупнейшими продавцами.
Успейте: скидка 15% до 29 мая
Пока следите за новостями — держите промокод Практикума на любой платный курс: по ссылке (можно просто нажать). Даёт скидку 15% при покупке, плюс дополнительно 5 мини-курсов и 5 книг стоимостью ~75 000 ₽. Но только до 29 мая — потом всё, промокод сгорит.
Бесплатные курсы в Практикуме тоже есть — по всем специальностям и направлениям, начать можно в любой момент, карту привязывать не нужно, если что.
