Quelle est une stratégie de nouvelle tentative sûre lorsqu’une intégration reçoit des erreurs de limitation du débit ?

lrichardson

Prenons le cas d’une intégration planifiée qui reçoit une réponse de limitation du débit à mi-parcours d’un lot. Relancer l’ensemble du traitement risque de créer des doublons, tandis que réessayer immédiatement chaque requête en échec pourrait maintenir l’intégration au-delà de la limite.

Comment combineriez-vous les points de contrôle, les délais avant nouvelle tentative et la protection contre les doublons dans cette situation ? Que devrait voir un administrateur pendant que le traitement attend avant de réessayer ? Supposez que l’API externe puisse fournir des indications sur le moment où réessayer, mais que certaines requêtes puissent également échouer pour des raisons qu’attendre ne permettra pas de résoudre.

emorris

Suivez les recommandations de nouvelle tentative du fournisseur lorsqu’elles sont disponibles ; sinon, appliquez une stratégie de temporisation avec recul progressif limité et variation aléatoire pour les échecs pouvant faire l’objet d’une nouvelle tentative. Enregistrez la progression et rendez les écritures idempotentes à l’aide de clés d’enregistrement stables. Les échecs d’authentification et de validation doivent être traités séparément. La vue d’administration doit afficher le dernier point de contrôle, le nombre d’éléments en attente, la prochaine tentative et le moment où une intervention est nécessaire.