Architecture
Diagramme d'architecture de résilience par disjoncteur montrant la machine à états complète avec les états fermé, ouvert et semi-ouvert, le suivi du seuil de défaillance, le timer de récupération et les stratégies de réponse de repli pour protéger les services des défaillances en cascade. Ce modèle visualise le pattern disjoncteur en détail, incluant comment le disjoncteur transite entre les états en fonction des compteurs de succès et d'échec. Essentiel pour construire des microservices tolérants aux pannes qui se dégradent gracieusement sous charge.
Code FlowZap complet
Client { # Client Service
n1: circle label:"Service Call"
n2: rectangle label:"Circuit Breaker Proxy"
n3: rectangle label:"Receive Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Breaker.n5.handle(top) [label="Check State"]
n3.handle(right) -> n4.handle(left)
}
Breaker { # Circuit Breaker
n5: diamond label:"Circuit State?"
n6: rectangle label:"Forward Request (Closed)"
n7: rectangle label:"Return Fallback (Open)"
n8: rectangle label:"Test Request (Half-Open)"
n9: rectangle label:"Track Success"
n10: rectangle label:"Track Failure"
n11: diamond label:"Failure Threshold?"
n12: rectangle label:"Trip Circuit Open"
n13: rectangle label:"Reset to Closed"
n14: rectangle label:"Start Recovery Timer"
n5.handle(right) -> n6.handle(left) [label="Closed"]
n5.handle(bottom) -> n7.handle(top) [label="Open"]
n5.handle(left) -> n8.handle(right) [label="Half-Open"]
n6.handle(bottom) -> Downstream.n15.handle(top) [label="Forward"]
n7.handle(top) -> Client.n3.handle(bottom) [label="Cached/Default"]
n8.handle(bottom) -> Downstream.n15.handle(top) [label="Probe"]
n9.handle(right) -> n13.handle(left) [label="Healthy"]
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left) [label="Exceeded"]
n11.handle(top) -> n6.handle(bottom) [label="Below"]
n12.handle(right) -> n14.handle(left) [label="Cooldown"]
n14.handle(top) -> n8.handle(bottom) [label="Timer Expired"]
}
Downstream { # Downstream Service
n15: rectangle label:"Process Request"
n16: diamond label:"Response OK?"
n17: rectangle label:"Return Success"
n18: rectangle label:"Return Error/Timeout"
n15.handle(right) -> n16.handle(left)
n16.handle(right) -> n17.handle(left) [label="200"]
n16.handle(bottom) -> n18.handle(top) [label="5xx/Timeout"]
n17.handle(top) -> Breaker.n9.handle(bottom) [label="Success"]
n18.handle(top) -> Breaker.n10.handle(bottom) [label="Failure"]
n17.handle(top) -> Client.n3.handle(bottom) [label="Response"]
}
Pourquoi ce workflow ?
When a downstream service fails, continuing to send requests wastes resources and can cascade failures across the entire system. The circuit breaker pattern detects failures, stops sending requests to unhealthy services, and automatically recovers when the service heals—preventing cascading failures and enabling graceful degradation.
Comment ça fonctionne
- Step 1: The circuit breaker proxy intercepts all outbound requests to the downstream service.
- Step 2: In the closed state, requests pass through normally and success/failure counts are tracked.
- Step 3: When failures exceed the configured threshold, the circuit trips to the open state.
- Step 4: In the open state, requests immediately return a fallback response without contacting the downstream service.
- Step 5: After a recovery timer expires, the circuit enters the half-open state and sends a test request.
- Step 6: If the test succeeds, the circuit resets to closed; if it fails, it returns to open.
Alternatives
Simple retry logic does not prevent cascading failures. Timeout-based approaches waste resources waiting. Libraries like Resilience4j, Polly, or Hystrix implement circuit breakers. This template visualizes the complete state machine for understanding the pattern.
Key Facts
| Template Name | Architecture de résilience par disjoncteur |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture d'orchestration AWS Step Functions avec des workflows de machine à états incluant des états de choix, du traitement parallèle, des patterns d'attente de callback et un rollback de compensation pour les étapes échouées. Ce modèle représente l'orchestration de workflows serverless où des processus multi-étapes complexes sont définis comme des machines à états avec gestion des erreurs et logique de retry intégrées. Critique pour les équipes construisant des workflows serverless fiables nécessitant une approbation humaine ou des processus de longue durée.
Architecture
Diagramme d'architecture d'isolation par cloison avec des pools de threads séparés pour les charges de travail critiques, standard et batch, chacun avec des pools de connexions indépendants, une détection d'épuisement et des stratégies de contre-pression pour empêcher une charge de travail d'affamer les autres. Ce modèle représente le pattern bulkhead inspiré des compartiments de coque de navire, où l'isolation des ressources garantit qu'une défaillance ou surcharge dans un composant ne peut pas se propager aux autres. Critique pour les systèmes nécessitant une disponibilité garantie pour les opérations hautement prioritaires.
Architecture
Diagramme d'architecture de retry avec backoff exponentiel montrant le moteur complet de politique de retry avec classification des erreurs retryables vs non-retryables, calcul de délai exponentiel avec jitter, seuils de tentatives maximales et gestion gracieuse de l'épuisement. Ce modèle représente le pattern de résilience essentiel pour gérer les défaillances transitoires dans les systèmes distribués, prévenant les problèmes de thundering herd par des délais de backoff aléatoires. Fondamental pour toute communication inter-services dans les architectures cloud.
Architecture
Diagramme d'architecture du pattern ambassador avec un proxy sidecar local gérant l'injection d'en-têtes d'authentification, le disjoncteur, la logique de retry et la collecte de métriques pour les requêtes sortantes vers des API tierces externes. Ce modèle représente le pattern ambassador où un service auxiliaire fonctionnant aux côtés de l'application décharge les préoccupations transversales pour la communication externe. Utile pour les équipes s'intégrant avec des services tiers peu fiables nécessitant des wrappers de résilience.
patterns
Pattern de résilience de disjoncteur avec états fermé, ouvert et semi-ouvert pour protéger les services des défaillances en cascade avec tests de récupération automatique.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.