Le stock sous charge.Le stock sous commandes concurrentes.

1. 01Plusieurs clients et commerciaux peuvent commander le même SKU au même moment.
2. 02Les réservations, confirmations, annulations et expirations modifient la quantité disponible selon des transitions distinctes.
3. 03Les clients mobiles peuvent réessayer une requête après timeout, même si le serveur a déjà exécuté l’opération.
4. 04Les files d’événements et services externes ajoutent des traitements asynchrones qui peuvent arriver en retard ou en double.

Sous faible charge, presque toute implémentation semble correcte. Les anomalies apparaissent dans les interleavings rares, les retries et les pannes partielles.

• Garantir que le stock réservé ne dépasse jamais le stock disponible.
• Rendre les commandes idempotentes malgré les retries réseau.
• Empêcher les requêtes d’un tenant d’observer ou modifier les données d’un autre.
• Réconcilier les événements asynchrones sans double consommation.

Une réservation transactionnelle et des commandes idempotentes peuvent maintenir les invariants de stock sous contention, retries et pannes partielles.

1. 01

   Charge connue

2. 02

   Commandes parallèles

3. 03

   Réservation atomique

4. 04

   Événements

5. 05

   Fault injection

6. 06

   Réconciliation

Le benchmark génère des commandes parallèles avec une graine reproductible, mesure chaque transition et réconcilie le résultat avec les invariants de stock.

1. 01Initialiser un catalogue, des tenants, des clients et un stock connu.
2. 02Générer des vagues concurrentes sur des SKU ciblés et des paniers mixtes.
3. 03Injecter retries, timeouts, annulations et traitements asynchrones dupliqués.
4. 04Observer latence, erreurs, deadlocks, files et saturation des connexions.
5. 05Vérifier les invariants transactionnels après chaque vague.
6. 06Rejouer la même graine après correction pour confirmer la non-régression.

Le protocole combine charge progressive, pics, endurance et fault injection. Chaque campagne publie versions, infrastructure, données et paramètres du générateur.

• Montée progressive pour localiser le premier goulot mesurable.
• Pic sur SKU fortement contesté avec stock inférieur à la demande totale.
• Test d’endurance pour détecter fuite mémoire, accumulation de file et dérive de latence.
• Retries et duplications pour vérifier l’idempotence de bout en bout.
• Arrêt contrôlé d’un worker ou service pour observer la reprise.
• Requête inter-tenant négative sur chaque opération critique.

Ces indicateurs définissent le protocole de mesure. Ils ne constituent pas des résultats publiés tant qu’un pilote ou le client n’a pas validé les données.

Ce qui doit faire échouer ou limiter le système

• Deux transactions lisent le même stock disponible avant mise à jour.
• Un retry crée une seconde commande après un timeout ambigu.
• Un événement consommé deux fois libère ou consomme le stock deux fois.
• La contention épuise les connexions et propage des timeouts en cascade.

1. 01Inclure le tenant dans chaque contrainte, requête, clé d’idempotence et événement.
2. 02Masquer les secrets et données clients dans les scripts et résultats publiés.
3. 03Limiter le benchmark à des environnements contrôlés et des quotas explicites.
4. 04Journaliser les changements de stock avec identité, cause et corrélation.

1. 01Le débit n’a pas de valeur si les invariants transactionnels sont violés.
2. 02Le p95 et le p99 révèlent la contention que la moyenne masque.
3. 03L’idempotence doit couvrir la commande, le paiement, le stock et les événements.
4. 04Un benchmark sans configuration publiée n’est pas reproductible.