Shopify remplace Redis par MySQL : la vraie leçon

Contre l’intuition dominante dans le monde du dev, Shopify a abandonné Redis au profit de MySQL pour gérer les réservations d’inventaire en temps réel. Au cœur de cette migration : la clause SKIP LOCKED, des clés composites et la puissance sous-estimée des transactions ACID. Retour sur une décision architecturale qui fait parler.

Deux bases, trop de bugs

Pendant des années, Shopify maintenait deux systèmes distincts pour gérer son inventaire lors du checkout. Comme le résume le site Hello Interview : « Pendant des années, ces deux étapes se déroulaient dans des bases de données différentes. Redis enregistrait le nombre d’unités. »

Cette architecture duale générait des classes entières de bugs. Un paiement pouvait aboutir sans que l’inventaire soit réclamé, ou l’inverse. Des oversells, des réservations perdues, le genre de problèmes qui, à l’échelle de Shopify, représentent des milliers de marchands impactés.

La migration vers MySQL : tout dans la même transaction

La solution adoptée par Shopify a consisté à co-localiser les réservations d’inventaire avec le ledger d’inventaire dans la même base MySQL. En enveloppant les opérations de réservation et de réclamation dans une transaction ACID unique, l’équipe a éliminé structurellement les incohérences entre les deux systèmes. (Shopify Engineering, dasroot.net)

Comme l’écrit le blog officiel : « En conservant les réservations et le registre des stocks dans la même base de données, nous obtenons l’ACID pour les réservations et les réclamations, corrigeant ainsi des catégories de bugs qui étaient possibles avec Redis. » Plus d’oversells, plus de réservations fantômes. (Hungry Minds Dev)

SKIP LOCKED et clés composites : les deux leviers techniques

Le cœur de la scalabilité repose sur la clause MySQL SKIP LOCKED. Le principe : si une transaction verrouille certaines lignes, les requêtes concurrentes les ignorent et se servent sur d’autres lignes disponibles. « No waiting on the same row, less contention », résume le billet de Shopify Engineering.

Mais SKIP LOCKED seul ne suffit pas. Un modèle naïf avec une ligne par unité d’inventaire aurait explosé : un article avec 50 000 unités sur 10 emplacements, c’est 500 000 lignes. Les requêtes de réservation auraient été trop lentes. (Shopify Engineering)

L’équipe a donc utilisé des clés composites pour optimiser la structure des données et éviter cette volumétrie excessive. (dasroot.net)

Le vrai goulot d’étranglement n’était pas là où on le cherchait

C’est peut-être la leçon la plus précieuse de cette migration. Alexandre Zajac le formule bien sur Substack : « La véritable leçon de Shopify : le goulot d’étranglement se situe rarement là où on le cherche. Ils ont optimisé les verrous et les requêtes pendant des semaines ; la solution résidait dans l’infrastructure : la mise en commun des connexions et le délai de transaction dans un code qu’ils ne mesuraient même pas. » (Hungry Minds Dev)

La symptomatologie était trompeuse : un CPU faible mais une forte file d’attente (queuing).
Le problème n’était pas de calcul mais de plomberie réseau et de gestion des connexions. Un rappel utile que le monitoring doit couvrir l’ensemble du chemin, pas seulement les composants qu’on soupçonne.

Et la communauté, elle en pense quoi ?

Sur Hacker News, des développeurs mentionnent une approche alternative : déduire la réservation de l’inventaire lors du démarrage de la commande dans la même transaction, avec un processus de fond pour restituer les unités en cas d’abandon ou de timeout.

Sur Reddit, le ton est plus pragmatique. Plusieurs commentateurs soulignent que la gestion de réservation d’inventaire pendant quelques minutes lors d’un checkout n’est pas une technologie nouvelle, et que des solutions similaires auraient pu être implémentées avec d’anciennes versions de MySQL. (Reddit r/programming)

Ces réactions illustrent un débat sain. Mais ce que Shopify démontre ici, c’est surtout qu’à une échelle considérable, une base relationnelle classique, bien utilisée, peut faire le travail qu’on délègue parfois à des outils plus exotiques. Comme le conclut Alexandre Zajac : « Si vous envisagez d’utiliser Redis, Kafka ou une couche de coordination personnalisée pour l’exclusion mutuelle à haut débit, votre base de données existante pourrait déjà suffire. » (Hungry Minds Dev)

En tant que dev habitué à administrer des serveurs sous Debian, je trouve que ce retour d’expérience est un rappel salutaire : avant d’empiler les briques technologiques, il vaut mieux maîtriser en profondeur celles qu’on a déjà.