Concevoir des intégrations API e-commerce résilientes

Si votre panier dépend d'un appel synchrone à un ERP, votre panier est exactement aussi fiable que cet ERP. Le Vendredi fou, c'est un problème. Voici les patrons que je recommande sur chaque projet d'intégration.

1. Rendre chaque écriture idempotente

Chaque écriture externe doit accepter une clé d'idempotence — l'identifiant de commande, un UUID, n'importe quoi de stable. Les retries deviennent sûrs, les commandes en double disparaissent, et votre équipe support retrouve ses soirées.

2. Mettre une file d'attente entre eux et vous

Les appels synchrones directs couplent votre disponibilité à la leur. Une file (SQS, Pub/Sub, même Redis Streams) permet d'accepter la commande maintenant et de la livrer à l'ERP quand il est en bonne santé. Le client ne voit jamais la panne.

3. Réessayer avec backoff exponentiel et gigue

Si tout le monde réessaie au même rythme, vous créez un effet de troupeau qui maintient le système en aval à terre. Ajoutez de la gigue, plafonnez les retries et envoyez les échecs persistants vers une dead-letter queue alarmée.

4. Ajouter des disjoncteurs autour des partenaires fragiles

Si une API de taxes expire pendant 90 secondes d'affilée, arrêtez de l'appeler. Repliez-vous sur des taux mis en cache ou une valeur par défaut, alertez l'équipe et reprenez quand les sondes redeviennent vertes. Un panier dégradé vaut mieux qu'un panier cassé.

5. Tout instrumenter, puis faire confiance aux tableaux de bord

• Taux de requêtes, taux d'erreurs, latence p95/p99 par intégration
• Profondeur de file et âge du plus vieux message
• Taille de la dead-letter queue avec alertes pageables
• KPI d'affaires (commandes/min) superposés aux KPI d'infra

Quand quelque chose casse à 2 h du matin un Cyber Monday, vous ne voulez pas lire du code. Vous voulez lire un tableau de bord.

Les intégrations n'échouent pas quand vous les testez. Elles échouent quand le trafic est multiplié par 10 et que votre partenaire passe une mauvaise journée.