Imaginez qu’il vous reste 1 unité d’une sneaker limitée. L’utilisateur A est sur votre site Web. L’utilisateur B est sur votre application. Ils cliquent tous les deux sur “Acheter” exactement à la même milliseconde (12:00:00.001). Shopify reçoit deux demandes. S’il n’est pas géré correctement, la sneaker est vendue deux fois. Vous devez maintenant envoyer un e-mail à un client et annuler sa commande. C’est un désastre en matière de relations publiques.

6. Cohérence éventuelle (la règle des 2 secondes)

Votre administrateur Shopify indique « Stock : 10 ». Votre ERP (NetSuite) indique « Stock : 8 ». Votre entrepôt (WMS) indique « Stock : 9 ». Qui a raison ? Aucun d’entre eux. Dans un système distribué, la cohérence est éventuelle. Nous avons besoin d’une Source unique de vérité pour le stock « Alloué ». Nous utilisons Redis comme « table d’allocation » faisant autorité. Ce n’est qu’une fois la commande expédiée que nous décrémentons l’ERP.

7. Tampons de stock de sécurité

“Si le stock < 5, marquez comme étant en rupture de stock.” Il s’agit d’une stratégie rudimentaire mais efficace pour les articles à haut débit. Si vous vendez 100 articles par seconde, la latence de synchronisation (200 ms) signifie que vous risquez de survendre de 20 articles. Solution : Stock de sécurité dynamique. Si la vélocité des ventes > 10/min, augmentez le stock de sécurité à 10. Si la vitesse de vente < 1/min, réduisez le tampon de sécurité à 0. Cela maximise les ventes tout en vous protégeant des stocks négatifs.

9. Dark Stores et expédition depuis le magasin

L’inventaire ne se trouve pas seulement dans l’entrepôt. C’est dans les magasins de détail. Nous implémentons Omnicanal Sync. Le « Flagship Store » sur la 5e Avenue est également « Warehouse #2 ». Si l’entrepôt principal est OOS, le système vérifie l’inventaire du magasin. Il achemine la commande vers le magasin iPad. L’associé du magasin sélectionne, emballe et expédie. Cela débloque 20 % de stocks supplémentaires qui étaient auparavant « piégés » dans les étagères.

10. Synchronisation de la logistique de retour

Lorsqu’un retour est initié (« /returns »), l’article est techniquement « En transit ». Ce n’est pas “disponible à la vente”. Mais nous savons que ça revient. Pour les articles très demandés, nous pouvons activer les commandes en souffrance. “Disponible dans 5 jours” (Arrivée Prévue du Retour). Nous synchronisons les événements du transporteur logistique de retour (FedEx Scan) pour mettre à jour le statut dans Shopify. Cela récupère les revenus des ventes perdues.

11. Conclusion : verrouillage optimiste et Redis

Nous ne pouvons pas nous fier à la base de données indiquant simplement « stock = 1 ». Nous avons besoin d’un verrouillage distribué.

diagramme de séquence
    participant UtilisateurA
    participant UtilisateurB
    participant Redis
    participant Shopify

    UtilisateurA->>Redis : verrou SETNX : sku_123 1
    Redis ->> UserA : OK (verrouillage acquis)
    UtilisateurB->>Redis : verrou SETNX : sku_123 1
    Redis ->> Utilisateur B : ÉCHEC (verrouillé)
    
    UtilisateurA->>Shopify : Commander Créer
    Shopify ->> Utilisateur A : Commande réussie
    UtilisateurA->>Redis : verrouillage DEL : sku_123
    
    UserB->>UI : Afficher l'erreur « En rupture de stock »

1. Le système de réservation

Lorsqu’un utilisateur ajoute un article très chaud au panier, nous le réservons dans Redis pendant 10 minutes. Réservation SET :sku_123:user_abc EX 600 Cela diminue le stock disponible immédiatement, avant même que l’achat ait lieu. S’ils n’achètent pas dans les 10 minutes, la clé expire et le stock retourne dans le pool.

Webhooks pour la synchronisation

Lorsqu’une commande arrive, nous devons en informer immédiatement Amazon et TikTok. Le webhook INVENTORY_LEVEL_UPDATE de Shopify est notre déclencheur. Nous transmettons cet événement à un Event Bus (Amazon EventBridge). Les fonctions lambda de diffusion mettent à jour les marchés externes en parallèle. (Latence : <200 ms).

12. Gérer le « troupeau tonitruant »

Lorsque 50 000 utilisateurs accèderont au site à 10 heures du matin, votre base de données mourra. Se connecter à Postgres pour chaque vérification d’inventaire est un suicide. Redis gère 100 000 opérations/seconde. Nous utilisons la mise en cache en lecture.

L’application demande à Redis : « Stock pour le SKU-123 ? »
Redis dit : « Mademoiselle ».
L’application demande à DB : « Le stock est de 100 ».
L’application indique à Redis : “SET SKU-123 100 TTL 10sec”. Cela réduit la charge de la base de données de 99 %. Mais que se passe-t-il si 1 000 demandes échouent exactement au même moment ? Ils ont tous touché la DB. Nous utilisons Probabilistic Early Expiration ou Request Coalescing (SingleFlight) pour garantir qu’UNE seule requête atteint la base de données pour réchauffer le cache.

Pourquoi Maison Code en parle

Chez Maison Code, nous concevons des Systèmes de lancement à haute température. Nous avons survécu au trafic du Black Friday pour les plus grandes marques de streetwear. Nous savons que la « survente » n’est pas un « problème opérationnel » ; c’est un “échec architectural”. Nous construisons des mécanismes de verrouillage distribué qui garantissent une forte cohérence même à grande échelle. Nous apprécions votre réputation. Une commande annulée est un client perdu à jamais.

14. Conclusion

La synchronisation des stocks est le problème le plus difficile du commerce électronique. Il lutte contre la physique (latence) et la probabilité (conditions de course). Vous ne pouvez pas gagner avec les « requêtes simples ». Vous avez besoin de mise en cache, de verrouillage et de mise en file d’attente. Vous devez concevoir pour l’échec.

Vendez-vous trop pendant les drops ?

Nous mettons en œuvre une synchronisation d’inventaire haute performance basée sur Redis pour garantir 0 % de survente.

Embauchez nos architectes.