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.
Code FlowZap complet
Caller { # Calling Service
n1: circle label:"Initiate Request"
n2: rectangle label:"Send HTTP Request"
n3: rectangle label:"Receive Response"
n4: circle label:"Request Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> RetryPolicy.n5.handle(top) [label="Execute"]
n3.handle(right) -> n4.handle(left)
}
RetryPolicy { # Retry Policy Engine
n5: rectangle label:"Attempt Request"
n6: diamond label:"Response Status?"
n7: rectangle label:"Return Success"
n8: diamond label:"Retryable Error?"
n9: rectangle label:"Return Permanent Failure"
n10: rectangle label:"Calculate Backoff Delay"
n11: diamond label:"Max Retries Exceeded?"
n12: rectangle label:"Wait with Jitter"
n13: rectangle label:"Return Exhausted Error"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="2xx"]
n6.handle(bottom) -> n8.handle(top) [label="Error"]
n7.handle(top) -> Caller.n3.handle(bottom) [label="Success"]
n8.handle(right) -> n10.handle(left) [label="429/503/Timeout"]
n8.handle(bottom) -> n9.handle(top) [label="400/401/404"]
n9.handle(top) -> Caller.n3.handle(bottom) [label="Non-Retryable"]
n10.handle(right) -> n11.handle(left) [label="2^n * base"]
n11.handle(bottom) -> n13.handle(top) [label="Yes"]
n11.handle(right) -> n12.handle(left) [label="No"]
n12.handle(top) -> n5.handle(bottom) [label="Retry"]
n13.handle(top) -> Caller.n3.handle(bottom) [label="Max Retries"]
}
Target { # Target Service
n14: rectangle label:"Process Request"
n15: diamond label:"Service Healthy?"
n16: rectangle label:"Return 200 OK"
n17: rectangle label:"Return 503 Unavailable"
n14.handle(right) -> n15.handle(left)
n15.handle(right) -> n16.handle(left) [label="Yes"]
n15.handle(bottom) -> n17.handle(top) [label="No"]
n16.handle(top) -> RetryPolicy.n6.handle(bottom) [label="Success"]
n17.handle(top) -> RetryPolicy.n6.handle(bottom) [label="Error"]
n5.handle(bottom) -> Target.n14.handle(top) [label="HTTP"]
}
Pourquoi ce workflow ?
Transient failures (network blips, temporary overloads) are inevitable in distributed systems. Naive retry strategies with fixed intervals cause thundering herd problems where all clients retry simultaneously. Exponential backoff with jitter spreads retries over time, giving the failing service time to recover.
Comment ça fonctionne
- Step 1: The calling service sends a request to the target service.
- Step 2: If the response indicates a transient error (429, 503, timeout), the retry policy activates.
- Step 3: Non-retryable errors (400, 401, 404) are returned immediately without retry.
- Step 4: The backoff delay is calculated as 2^n × base_delay with random jitter.
- Step 5: If the maximum retry count is exceeded, an exhaustion error is returned to the caller.
- Step 6: Successful responses reset the retry counter for subsequent requests.
Alternatives
Fixed-interval retries cause thundering herds. No retries mean transient failures become permanent. Circuit breakers complement retries by stopping attempts to known-failing services. This template shows the complete retry policy engine.
Key Facts
| Template Name | Architecture de retry avec backoff exponentiel |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de file de lettres mortes avec politiques de retry, backoff exponentiel, seuils de tentatives maximales, routage DLQ pour les messages échoués, alertes opérationnelles et workflows de retraitement manuel. Ce modèle représente le pattern critique de gestion des erreurs pour les systèmes de messagerie asynchrone, garantissant qu'aucun message n'est silencieusement perdu lors d'un échec de traitement. Essentiel pour construire des systèmes événementiels fiables avec des mécanismes de récupération appropriés.
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.
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 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.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.