Une API tierce dont vous dépendez commence à expirer par intermittence. Que faites-vous ?

Contenez d'abord : mettez un délai limite agressif pour que leur latence ne devienne pas la vôtre, reprenez avec attente exponentielle et jitter, sur les appels idempotents uniquement, et placez un disjoncteur devant pour arrêter de marteler quelque chose qui est déjà à terre. Décidez ensuite à quoi ressemble un comportement dégradé : mettre le travail en file pour plus tard, servir une valeur en cache, ou faire échouer cette seule fonctionnalité pendant que le reste du produit continue.

La première chose que je vérifie, c'est si on a seulement un délai limite, parce que le défaut dans beaucoup de clients HTTP est en pratique l'infini, et c'est comme ça qu'un prestataire lent remplit votre pool de workers et fait tomber des endpoints qui n'ont rien à voir avec lui. Donc un délai limite agressif, plus serré que mon propre SLA. Ensuite les reprises, mais seulement sur les appels sûrs à répéter, avec attente exponentielle et jitter, parce que des reprises synchronisées depuis toutes les instances transforment leur ralentissement en panne complète. Un disjoncteur va devant, pour qu'après une série d'échecs on arrête d'appeler un moment et qu'on échoue vite plutôt que de faire la file. Puis la question produit, qui est la plus intéressante : que devrait voir l'utilisateur ? Pour un appel de validation d'adresse, je laisserais passer la commande en la marquant pour vérification. Pour une autorisation de paiement, je ne peux pas faire semblant, donc je mets la tentative en file et je le dis honnêtement à l'utilisateur. Et je serais sur leur canal de support avec des identifiants de requête pendant tout ce temps.