Patterns de résilience : circuit breaker, retry, timeout

J'accompagnais un client dans le secteur du retail en ligne (25 développeurs). En six mois, trois incidents P1, à chaque fois pendant des pics de trafic. Le service de recommandations devenait lent, les threads du service produit s'accumulaient en attente, le pool de connexions s'épuisait, et le service produit tombait à son tour. La homepage devenait indisponible.

Le service de recommandations avait une excuse valable : les pics de charge. Le service produit n'en avait pas. Il n'avait simplement aucun mécanisme pour se protéger d'un voisin défaillant.

Deux heures de développement pour ajouter un timeout. Deux jours pour le circuit breaker. Zéro incident P1 lié aux recommandations depuis lors. Les recommandations continuent de tomber lors des pics, mais ça reste isolé.

C'est ce que les patterns de résilience font : ils n'éliminent pas les pannes, ils empêchent qu'une panne locale devienne un effondrement global.

La cascade failure : pourquoi les systèmes distribués s'effondrent en bloc

Sans mécanisme de protection, les appels vers des services externes dans un système distribué ont une propriété dangereuse : si le service cible ralentit, les appelants attendent, leurs ressources se consomment, et ils deviennent eux-mêmes défaillants. Ce phénomène est aggravé par le couplage temporel entre services, qui crée des dépendances implicites d'ordre ou de timing difficiles à détecter jusqu'en production.

Michael Nygard a documenté ce pattern en détail dans "Release It!" (2007), l'ouvrage de référence sur la résilience des systèmes en production. Sa conclusion : la stabilité ne se construit pas par l'optimisme (espérer que les services tiers restent disponibles), mais par la conception défensive (prévoir leur défaillance et la gérer).

Selon Gartner, une heure de downtime coûte en moyenne 300 000€ pour une application business critique. Les 3 patterns décrits ici sont des assurances contre ce coût.

Pattern 1 : Timeout

Le timeout est le premier niveau de protection, et le plus souvent absent. Un appel vers un service externe sans timeout peut attendre indéfiniment, bloquant les ressources de l'appelant.

Principe : tout appel vers un service externe (HTTP, base de données, cache, message broker) doit avoir un timeout explicite défini dans le code. Si le service ne répond pas dans ce délai, l'appel est considéré comme échoué et les ressources sont libérées.

Comment définir la valeur du timeout :

• Mesurer le p99 (99ème percentile) de la latence du service cible sur les 30 derniers jours
• Multiplier par 2 à 3 pour le timeout
• Ne jamais utiliser la valeur par défaut du client HTTP (souvent 30 secondes à 2 minutes, beaucoup trop long)

// Exemple avec OkHttp (Java)
OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(2, TimeUnit.SECONDS)  // temps max pour établir la connexion
    .readTimeout(5, TimeUnit.SECONDS)     // temps max pour recevoir la réponse
    .writeTimeout(5, TimeUnit.SECONDS)    // temps max pour envoyer la requête
    .build();

À quelle couche définir le timeout : aussi près que possible de l'appel externe. Un timeout au niveau de l'API gateway seul ne protège pas les services internes.

Pattern 2 : Retry avec backoff exponentiel

Un service peut échouer de façon transitoire : surcharge momentanée, redémarrage d'instance, pic de latence. Un retry permet de retenter l'opération après un délai, sans inonder le service défaillant de requêtes supplémentaires.

Principe du backoff exponentiel : le délai entre les tentatives augmente exponentiellement. Avec un jitter (variation aléatoire) pour éviter que tous les appelants retentent exactement au même moment, ce qui recréerait la surcharge qu'on cherche à éviter.

import time
import random

def call_with_retry(func, max_retries=3, base_delay=0.1):
    for attempt in range(max_retries):
        try:
            return func()
        except TransientError as e:
            if attempt == max_retries - 1:
                raise  # dernière tentative — propager l'erreur
            delay = base_delay * (2 ** attempt) + random.uniform(0, 0.1)  # jitter
            time.sleep(delay)

Quand ne pas retenter :

• Erreurs non-transientes (404, 401, 403, validation error) : retenter ne changera rien
• Opérations non-idempotentes : retenter peut dupliquer l'effet (créer deux commandes au lieu d'une)

Pattern 3 : Circuit Breaker

Le circuit breaker est le pattern le plus important pour prévenir les cascade failures. Son principe est emprunté à l'électricité : quand un circuit est en surcharge, le disjoncteur coupe le courant pour protéger le reste du circuit.

Les 3 états :

Closed (normal) : les appels passent normalement. Le circuit breaker monitore le taux d'échec.

Open : le taux d'échec a dépassé le seuil (par exemple, plus de 50% d'échecs sur les 10 derniers appels). Les appels échouent immédiatement sans atteindre le service défaillant. Cela protège le service défaillant de la surcharge et protège l'appelant d'une accumulation de threads.

Half-Open : après un délai (30 secondes par exemple), le circuit breaker laisse passer quelques appels de test. Si ils réussissent, retour à Closed. Sinon, retour à Open.

// Exemple avec Resilience4j (Java)
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)
    .waitDurationInOpenState(Duration.ofSeconds(30))
    .slidingWindowSize(10)
    .build();

CircuitBreaker circuitBreaker = CircuitBreaker.of("paymentService", config);

Supplier<Payment> decoratedCall = CircuitBreaker
    .decorateSupplier(circuitBreaker, () -> paymentService.processPayment(request));

// Exemple avec opossum (Node.js)
const CircuitBreaker = require('opossum');

const breaker = new CircuitBreaker(paymentService.processPayment, {
    timeout: 3000,
    errorThresholdPercentage: 50,
    resetTimeout: 30000
});

breaker.fallback(() => ({ status: 'payment_service_unavailable' }));

Les compléments : bulkhead et fallback

Bulkhead : isoler les ressources par service externe. Chaque service externe a son propre pool de threads ou de connexions : une dégradation d'un service ne consomme pas toutes les ressources de l'appelant.

Fallback : définir un comportement de repli quand le circuit est ouvert. Pas "retourner une erreur 500", mais retourner un résultat dégradé acceptable.

• Service de recommandations indisponible → retourner des recommandations statiques ou populaires
• Service de notation indisponible → afficher la note moyenne sans recalcul temps-réel
• Service de paiement indisponible → mettre la commande en queue pour traitement différé

Votre système doit fonctionner de façon dégradée quand un service non-critique est indisponible. Il ne doit pas être entièrement indisponible.

Ordre d'implémentation

1. Timeout d'abord (1 journée) : ajouter des timeouts explicites sur tous les appels vers des services externes. C'est la correction la plus rapide et la plus impactante.
2. Retry sur les erreurs transientes (2 à 3 jours) : identifier les erreurs transientes dans votre système et ajouter un retry avec backoff exponentiel. S'assurer que les opérations retriées sont idempotentes.
3. Circuit breaker sur les services critiques (1 semaine) : identifier les 5 à 10 dépendances externes les plus critiques et implémenter le circuit breaker avec monitoring.

En moins de 2 semaines, votre système est significativement plus résilient.

FAQ sur les patterns de résilience