Retry, Timeout & Backoff, ou l'échec qu'on prévoit au lieu de le subirRetry, Timeout & Backoff, or the failure you plan for instead of enduring

L'autre côté ne répond pas. Est-ce un bug, ou l'état normal du réseau ?The other side doesn't answer. Is it a bug, or the network's normal state?

Le Vol 6 a tracé la frontière réseau ; ce numéro affronte ce qu'elle rend inévitable. Un appel entre services peut être lent, expirer, ou échouer alors que le service va parfaitement bien — un paquet perdu, un redéploiement, une microseconde de surcharge. Écrit naïvement, l'appel attend l'infini, puis ou bien abandonne au premier hoquet, ou bien réessaie en boucle et aggrave la panne. Ce qui varie d'un appel à l'autre, ce n'est pas s'il peut échouer : c'est comment on traite cet échec. Le réflexe : considérer l'échec transitoire comme un état normal du réseau, et le gérer avec trois outils — un timeout pour ne pas attendre l'infini, un retry pour absorber le transitoire, un backoff pour ne pas réessayer en rafale.Vol 6 drew the network boundary; this issue faces what it makes inevitable. A call between services can be slow, time out, or fail while the service is perfectly fine — a dropped packet, a redeploy, a microsecond of overload. Written naively, the call waits forever, then either gives up at the first hiccup, or retries in a loop and worsens the outage. What varies between calls isn't whether they can fail: it's how you treat that failure. The reflex: treat transient failure as a normal state of the network, and handle it with three tools — a timeout so you don't wait forever, a retry to absorb the transient, a backoff so you don't retry in bursts.

# un appel inter-services écrit comme s'il répondait toujours, vite, et une seule fois
def charge(order_id, amount):
    resp = http.post("http://billing/charge", json={...})   # 💥 aucun timeout : attend l'infini
    return resp.json()["status"]                            #     si billing rame, on rame avec lui

# et le jour où ça échoue, deux réflexes naïfs, tous deux faux :
#   - on n'essaie pas → un hoquet réseau d'1s fait échouer une commande qui aurait abouti
#   - on réessaie en boucle, tout de suite → on tape un service déjà au sol, et on
#     re-poste sans clé : si le 1er appel avait débité avant le timeout, on débite DEUX fois.
# l'échec réseau n'est pas une exception rare : c'est un état NORMAL du fil.

L'attente infinie fige tout, et le retry naïf achève le blessé.The infinite wait freezes everything, and the naive retry finishes off the wounded.

Mal gérer l'échec réseau a trois coûts qui se renforcent. Sans timeout, une dépendance lente fige tous ses appelants : les threads et les connexions s'accumulent en attendant une réponse qui ne vient pas, et c'est tout le système qui se bloque pour un seul service en peine. Avec un retry naïf — immédiat, en boucle —, on tape un service déjà au sol : tous les clients réessaient en même temps à la milliseconde où il hoquette, et la tempête de retries transforme un micro-incident en panne franche. Et sans idempotence, chaque retry qui aboutit après un premier appel réussi-mais-perdu duplique l'effet : on débite, on notifie, on crée deux fois. Trois manières de transformer un échec transitoire — qui se serait résolu seul — en incident majeur.Mishandling network failure has three costs that reinforce each other. Without a timeout, a slow dependency freezes all its callers: threads and connections pile up awaiting an answer that never comes, and the whole system locks over one struggling service. With a naive retry — immediate, in a loop —, you hammer a service already down: every client retries at the same millisecond it hiccups, and the retry storm turns a micro-incident into a hard outage. And without idempotency, every retry that lands after a first succeeded-but-lost call duplicates the effect: you charge, notify, create twice. Three ways to turn a transient failure — which would have resolved itself — into a major incident.

def charge(order_id, amount):
    while True:                                  # 💥 boucle sans borne ni espacement
        try:
            return http.post("http://billing/charge",
                             json={"amount": amount})   # 💥 aucune clé : rejeu = double débit
        except (Timeout, ConnError):
            continue        # 💥 on re-tape AUSSITÔT — pile quand billing est au plus mal
# pas de timeout → on peut attendre l'infini · pas de backoff → tempête ·
# pas d'idempotence → le client est débité autant de fois que la boucle tourne.

Le retry naïf fait la tempête — le timeout, le backoff et le jitter la calment.The naive retry storms — timeout, backoff and jitter calm it.

Les trois outils ne se comprennent qu'ensemble, en regardant la charge dans le temps. L'animation part de la tempête — quatre clients qui re-tapent en rafale synchronisée un service à terre —, puis applique chaque garde-fou : le timeout borne l'attente et arrête la boucle, le backoff espace les tentatives en allongeant les délais, le jitter les désynchronise par un peu de hasard. À chaque marche, la forêt de tentatives se clairseme, et le service passe du sol au rétablissement. Ce n'est pas un outil qui sauve, c'est leur combinaison.The three tools only make sense together, watching load over time. The animation starts from the storm — four clients re-hammering a downed service in synchronized bursts —, then applies each guardrail: the timeout bounds the wait and stops the loop, the backoff spaces attempts by lengthening delays, the jitter desynchronizes them with a bit of randomness. At each step, the forest of attempts thins, and the service goes from down to recovered. It's not one tool that saves, it's their combination.

def call_with_resilience(order_id, amount, max_tries=4):
    for attempt in range(max_tries):                    # retry BORNÉ, pas une boucle
        try:
            return billing.charge(amount,
                                  idempotency_key=order_id,   # rejouable sans double débit
                                  timeout=2.0)                # borne l'attente
        except Transient:                               # on ne retente QUE le transitoire
            if attempt == max_tries - 1: raise          # dernier essai → on propage
            delay = (2 ** attempt) + random.uniform(0, 1)   # backoff exponentiel + jitter
            sleep(delay)                                #  1s · 2s · 4s … + un peu de hasard

Tout retenter n'est pas être robuste. Le retry qui amplifie la panne.Retrying everything isn't being robust. The retry that amplifies the outage.

Le piège n'est pas le retry — c'est de retenter sans discernement. Deux dérives se cumulent. D'abord on retente ce qui ne se réparera jamais : un « 400 montant invalide » ne devient pas valide au cinquième essai, un « 409 déjà traité » non plus — on s'acharne sur des échecs définitifs, on gaspille du temps et on masque le vrai bug. Ensuite, les retries s'empilent en cascade : si chaque maillon d'une chaîne d'appels retente cinq fois, un clic devient cinq, puis vingt-cinq, puis cent vingt-cinq tentatives, et une lenteur en bout de chaîne remonte en avalanche qui sature tout l'amont. Le retry n'amortit l'échec que s'il est borné, réservé au transitoire, et non répété à chaque étage. Bascule le toggle : cherche le retry qui s'acharne, et celui qui se multiplie.The trap isn't the retry — it's retrying indiscriminately. Two drifts compound. First you retry what will never heal: a '400 invalid amount' doesn't become valid on the fifth try, nor does a '409 already processed' — you hammer on definitive failures, waste time and mask the real bug. Then, retries stack in cascade: if each link of a call chain retries five times, one click becomes five, then twenty-five, then one hundred twenty-five attempts, and a slowness at the chain's end surges back as an avalanche that saturates everything upstream. The retry only cushions failure if it's bounded, reserved for the transient, and not repeated at every tier. Flip the toggle: hunt the retry that hammers, and the one that multiplies.

# on ne retente QUE ce qui est transitoire, et seulement si c'est rejouable sans dommage
def charge(order_id, amount):
    return retry(
        lambda: billing.charge(amount, idempotency_key=order_id, timeout=2.0),
        max_tries=4,
        backoff=expo_jitter,                  # 1s·2s·4s + hasard
        retry_on=[Timeout, ConnReset, HTTP503],   # transitoire : ça vaut le coup
        give_up_on=[HTTP400, HTTP409, HTTP422],   # définitif : retenter ne changera rien
    )
# 400 "montant invalide" ne deviendra jamais valide en réessayant : on échoue VITE.
# et la clé d'idempotence garantit qu'un rejeu ne débite pas deux fois.

L'échec qu'on subit, ou l'échec qu'on a prévu.Failure you endure, or failure you planned for.

Quand ne pas (sur-)retenterWhen not to (over-)retry

La résilience a un loyer : de la latence ajoutée, de la complexité, des effets à rendre rejouables. On appelle simplement, sans étage de retry — et c'est correct — quand :Resilience has rent: added latency, complexity, effects to make replayable. Just call, with no retry tier — and that's fine — when:

• l'appel est local, en mémoire : pas de réseau, pas d'échec transitoire à absorber. Emballer un appel de fonction dans un retry, c'est de la cérémonie (YAGNI, Vol 0 #3) qui n'a aucune panne à soigner.the call is local, in-memory: no network, no transient failure to absorb. Wrapping a function call in a retry is ceremony (YAGNI, Vol 0 #3) with no failure to cure.
• l'échec est définitif par nature : une validation, une autorisation refusée, une ressource qui n'existe pas. Retenter ne changera jamais le verdict — il faut échouer vite et rendre l'erreur, pas s'acharner.the failure is definitive by nature: a validation, a denied authorization, a resource that doesn't exist. Retrying will never change the verdict — you must fail fast and return the error, not hammer.
• une couche en amont retente déjà : empiler un retry sur un retry multiplie les tentatives en cascade. La résilience se place à un seul étage — souvent au plus près de l'appel faillible — pas à chacun.an upstream layer already retries: stacking a retry on a retry multiplies attempts in cascade. Resilience sits at a single tier — often closest to the fallible call — not at each one.

Le réflexe n'est donc pas « mets un retry partout, c'est robuste » : c'est « cet échec est-il transitoire et l'opération rejouable sans dommage ? Alors un retry borné, espacé, avec une issue pour ce qui résiste. Sinon, échoue vite, et franchement. »So the reflex isn't 'put a retry everywhere, it's robust': it's 'is this failure transient and the operation replayable without harm? Then a bounded, spaced retry, with an outcome for what resists. Otherwise, fail fast, and plainly.'

Mot de l'éditeurFrom the editor

Ce numéro ouvre le Vol 7 par le renversement qui fonde tout le volume : l'échec transitoire n'est pas une exception rare, c'est un état normal du réseau. Sur un seul process, un appel qui échoue est presque toujours un vrai bug ; sur le fil, l'échec passager est permanent, et la plupart se résout seul en quelques millisecondes. Toute la résilience découle de ce changement de regard : on ne subit plus l'échec, on le prévoit — borné par un timeout, absorbé par un retry espacé et désynchronisé, réservé au transitoire, rendu rejouable par l'idempotence, et rattrapé par une file quand il résiste. Quatre réglages qui transforment un événement catastrophique en routine silencieuse.This issue opens Vol 7 with the reversal that founds the whole volume: transient failure isn't a rare exception, it's a normal state of the network. On a single process, a failing call is almost always a real bug; on the wire, passing failure is constant, and most resolves itself in milliseconds. All resilience flows from this shift in gaze: you no longer endure failure, you plan for it — bounded by a timeout, absorbed by a spaced and desynchronized retry, reserved for the transient, made replayable by idempotency, and caught by a queue when it resists. Four settings that turn a catastrophic event into a silent routine.

Mais le retry a une limite : si le service d'en face est vraiment mort — pas un hoquet, une panne franche —, continuer à le solliciter, même espacé, ne fait que l'empêcher de se relever et gaspiller nos propres ressources. C'est le sujet du #2, le Circuit Breaker : cesser d'appeler un service à terre pour le laisser respirer, et échouer immédiatement le temps qu'il se rétablisse. Puis le #3 affrontera l'autre moitié de la question du volume — « ou répond deux fois ? » — en regardant la vérité en face : « exactly-once » n'existe pas sur un réseau. On conçoit pour le « au moins une fois », avec l'idempotence aperçue ici et la Saga pour orchestrer ce qui ne tient plus dans une transaction. Le fil rouge : le réseau ne ment pas, il oublie, répète et tarde — et on code en le sachant.But the retry has a limit: if the service across is truly dead — not a hiccup, a hard outage —, continuing to call it, even spaced, only keeps it from recovering and wastes our own resources. That's #2's subject, the Circuit Breaker: stop calling a downed service to let it breathe, and fail immediately while it recovers. Then #3 will face the volume's other half — 'or answers twice?' — by looking the truth in the eye: 'exactly-once' doesn't exist on a network. You design for 'at least once', with the idempotency glimpsed here and the Saga to orchestrate what no longer fits in a transaction. The through-line: the network doesn't lie, it forgets, repeats and lags — and you code knowing it.

Les voisins que ce numéro débloqueThe neighbors this issue unlocks

• Exponential backoff — la stratégie d'espacement même : doubler le délai à chaque tentative (1s, 2s, 4s, 8s) pour laisser au service le temps de se relever. Sans elle, le retry frappe à fréquence constante et entretient la surcharge ; avec elle, la pression décroît à mesure que l'échec persiste.the spacing strategy itself: double the delay at each attempt (1s, 2s, 4s, 8s) to give the service time to recover. Without it, the retry strikes at constant frequency and sustains the overload; with it, pressure decreases as the failure persists.
• Jitter — le grain de hasard ajouté au backoff. Sans lui, tous les clients qui ont échoué ensemble réessaient ensemble — des vagues synchronisées qui re-saturent le service à chaque palier. Le jitter disperse les tentatives dans le temps et dissout le thundering herd ; c'est le détail qui fait vraiment tenir le backoff à grande échelle. Sa forme la plus efficace, le « full jitter », tire au sort tout le délai entre zéro et le palier.the grain of randomness added to the backoff. Without it, all clients that failed together retry together — synchronized waves that re-saturate the service at each step. Jitter scatters attempts across time and dissolves the thundering herd; it's the detail that truly makes backoff hold at scale. Its most effective form, 'full jitter', draws the whole delay at random between zero and the step.
• Dead Letter Queue — l'issue de l'échec qui résiste à tous les retries. Plutôt que de le perdre en silence, on le dépose dans une file dédiée : il y sera rejoué, inspecté ou compensé, à la main ou plus tard. C'est ce qui distingue un système qui encaisse l'échec d'un système qui l'oublie — et le pont vers les files de messages (Vol 4 #2) et la Saga (#3).the outcome for the failure that resists all retries. Rather than losing it in silence, you drop it in a dedicated queue: there it will be replayed, inspected or compensated, by hand or later. It's what separates a system that absorbs failure from one that forgets it — and the bridge to message queues (Vol 4 #2) and the Saga (#3).

Le kata — écris-le, ne le relis pasThe kata — write it, don't reread it

# test_retry.py — la spec EST le harnais : fais-le passer au vert.
# un retry BORNÉ : il n'insiste que sur le transitoire, espace ses essais, sait s'arrêter.

def test_reussit_du_premier_coup():
    sonde = compteur(lambda: "ok")
    assert retry(sonde) == "ok"                  # aucun échec → aucun retry
    assert sonde.count == 1                       # un seul appel, transparent

def test_retente_le_transitoire_puis_reussit():
    sonde = echoue_n_fois(2, Transient, puis="ok")
    assert retry(sonde, max_tries=4) == "ok"     # 2 hoquets absorbés…
    assert sonde.count == 3                       # …le 3e essai passe

def test_borne_le_nombre_d_essais():
    sonde = compteur(dead)                        # dead lève Transient à chaque fois
    with raises(Transient): retry(sonde, max_tries=4)
    assert sonde.count == 4                        # 4 essais, pas une boucle infinie

def test_n_attend_pas_apres_le_dernier_essai():
    delays = capture_les_sleeps()
    with raises(Transient): retry(dead, max_tries=4)
    assert len(delays) == 3                        # 4 essais → 3 pauses : rien après le dernier

def test_backoff_croit_a_chaque_essai():
    delays = capture_les_sleeps()
    with raises(Transient): retry(dead, max_tries=4)
    assert delays[0] < delays[1] < delays[2]      # ~1s < ~2s < ~4s : l'espacement grandit

def test_echec_definitif_echoue_vite():
    sonde = compteur(lambda: leve(Invalid))       # 400 : verdict définitif
    with raises(Invalid): retry(sonde, max_tries=4)
    assert sonde.count == 1                        # on NE retente PAS : retenter ne le validera jamais