Comment appelez-vous un service dont vous dépendez et qui peut être lent ou en panne ?

Fixez un délai d'expiration explicite sur chaque appel, plus court que votre propre échéance, et ne comptez jamais sur la valeur par défaut de la bibliothèque cliente. Ne rejouez que les opérations idempotentes, avec backoff exponentiel plus jitter et un petit nombre borné de tentatives. Ajoutez un disjoncteur pour que des échecs répétés échouent vite au lieu de s'empiler, et définissez à quoi ressemble le mode dégradé : une valeur en cache, une réponse partielle, ou une erreur claire plutôt qu'une requête qui pend.

La première chose, c'est un délai d'expiration sur chaque appel sortant, choisi à partir de la distribution des latences plutôt qu'au hasard, et toujours plus court que l'échéance qu'on m'a donnée, pour que j'échoue avant que mon appelant abandonne. Je propage cette échéance restante vers l'aval, sinon le travail continue sur une requête que plus personne n'attend. Les reprises ne s'appliquent qu'aux appels idempotents, et même là avec backoff exponentiel et jitter, plafonnées à deux ou trois tentatives. La raison du plafond, c'est l'amplification : si chaque couche réessaie trois fois, un hoquet en bas devient un ordre de grandeur de charge en plus, et c'est ainsi qu'une dépendance lente se transforme en panne totale. J'aime donc aussi un budget de reprise, où les reprises sont limitées à un petit pourcentage du total des requêtes. Un disjoncteur se pose au-dessus pour qu'une fois les échecs au-delà d'un seuil j'échoue immédiatement pendant une période de repos, avec des sondages occasionnels, ce qui m'évite d'empiler des requêtes sur quelque chose qui souffre déjà. Et je décide d'avance de ce que veut dire dégradé ; sur un service de tarification, on servait le dernier prix en cache avec un indicateur de fraîcheur plutôt que de faire échouer le paiement.