Circuit breaker et bulkhead

Prérequis : cours 7.1.

Pourquoi

Quand un service est à genoux, continuer à l'appeler l'achève (et fige les appelants). Le circuit breaker coupe le courant ; le bulkhead empêche l'incendie de se propager. Les deux transforment la panne totale en dégradation partielle.

Concepts

• Circuit breaker : 3 états. Fermé (tout passe, on compte les échecs) → ouvert (seuil dépassé : on échoue vite sans appeler, avec fallback) → semi-ouvert (un essai prudent après délai ; succès = refermer). Comme un disjoncteur : il protège les deux côtés.
• Fallback : la réponse de secours (cache périmé, valeur par défaut, fonctionnalité désactivée proprement). Un breaker sans fallback = juste une erreur plus rapide — utile, mais moitié du bénéfice.
• Bulkhead (cloison) : isoler les ressources par dépendance (pool de threads/connexions dédié par service appelé). Le service lent sature SA cloison, pas toute l'app. Nom hérité des navires (compartiments étanches).

Exemple : seuils qui ont du sens

breaker paiement : 50 % d'échecs sur 20 appels → ouvert 30 s → essai
fallback : file « à traiter » + message « paiement différé de quelques minutes »
bulkhead : pool notif séparé du pool paiement (le SMS lent ne bloque pas le paiement)

Cas réel

Recommandations down un Black Friday : sans breaker, chaque page attend 30 s (timeout défaut) → tout le site à genoux pour un module « nice-to-have ». Avec : section masquée proprement, conversion quasi normale. Le fallback a rapporté des millions ce jour-là.

Pièges

• Seuil trop sensible (3 échecs = ouvert) : le breaker s'ouvre sur un hoquet. Calibrer sur le trafic réel.
• Fallback jamais testé : le jour J il est périmé/cassé. Tester les dégradations (game day, cf. DevOps 8.3).
• Breaker partout « au cas où » : sur les dépendances critiques et lentes ; pas sur l'appel local à 1 ms.

À retenir

Breaker = échouer vite + fallback, bulkhead = cloisons, seuils calibrés et fallbacks testés.