Synchronisation e-commerce vers ERP lors des pics de commandes
Une enseigne e-commerce traite 800 commandes par jour, avec des pics à 300 commandes par minute lors des ventes flash. Le site envoie des webhooks à un middleware qui appelle un ERP SOAP limité à 40 requêtes par seconde. Depuis deux mois, les incidents se multiplient : doublons de commandes, réponses 504, stocks négatifs et 2 % des commandes du dernier pic absentes de l’ERP. Le middleware réessaie trois fois sans clé d’idempotence, puis marque l’ordre en échec. Le service client corrige manuellement. La direction veut un flux fiable avant le Black Friday, sans remplacer l’ERP. Le budget cloud autorise une file managée et un petit service de réconciliation, mais pas une réécriture complète.
1. Proposez une architecture cible pour fiabiliser le flux, en expliquant le rôle de l’idempotence, de la file et du débit limité.
Read the worked answer
Architecture cible : le webhook est acquitté rapidement par une passerelle qui publie un message dans une file persistante, puis un worker traite le message vers l’ERP. Chaque message porte une clé d’idempotence stable, par exemple identifiant de commande plus type d’événement. Le worker vérifie un magasin de clés avant l’appel SOAP et enregistre la clé après succès ; un doublon de webhook ou une reprise après timeout ne crée donc pas une seconde commande. La file absorbe les pics : 300 commandes par minute représentent 5 commandes par seconde en moyenne, mais les rafales et les appels multiples par commande peuvent dépasser la limite de 40 requêtes par seconde. Un limiteur de débit côté worker, avec backoff exponentiel et jitter, protège l’ERP. Les échecs définitifs vont dans une file de rebut surveillée, et non dans un simple statut en échec. Enfin, la réconciliation compare périodiquement les commandes du site et celles de l’ERP pour détecter les pertes silencieuses.
2. Comment traitez-vous les doublons, les 504 et les 2 % de commandes manquantes ? Quels indicateurs et tests proposez-vous avant le Black Friday ?
Read the worked answer
Les doublons proviennent des réessais sans idempotence : il faut d’abord dédupliquer côté worker avec une contrainte unique sur la clé d’idempotence, puis auditer les commandes déjà créées en double. Les 504 indiquent un temps d’attente ERP trop long ou une saturation : le worker doit avoir un timeout court, réessayer uniquement les erreurs réessayables et laisser la file absorber la charge. Les 2 % manquantes peuvent venir d’un webhook perdu avant la file, d’un message en file de rebut non traité ou d’un marquage en échec sans reprise ; la réconciliation doit rechercher les commandes payées sans contrepartie ERP et les rejouer avec la même clé. Indicateurs : âge du message le plus ancien, débit d’entrée et de sortie, taux de 5xx, taux de doublons, taille de la file de rebut, écart de réconciliation. Tests : charge à deux fois le pic, coupure ERP de 5 minutes, rejeu d’un lot de messages, vérification qu’un même message traité trois fois ne crée qu’une commande.