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.
Code FlowZap complet
Gateway { # API Gateway
n1: circle label:"Incoming Request"
n2: rectangle label:"Classify Request Type"
n3: diamond label:"Request Category?"
n4: rectangle label:"Route to Critical Pool"
n5: rectangle label:"Route to Standard Pool"
n6: rectangle label:"Route to Batch Pool"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="Critical"]
n3.handle(bottom) -> n5.handle(top) [label="Standard"]
n3.handle(left) -> n6.handle(right) [label="Batch"]
n4.handle(bottom) -> CriticalPool.n7.handle(top) [label="Priority"]
n5.handle(bottom) -> StandardPool.n11.handle(top) [label="Normal"]
n6.handle(bottom) -> BatchPool.n15.handle(top) [label="Low Priority"]
}
CriticalPool { # Critical Thread Pool (10 threads)
n7: rectangle label:"Dedicated Connection Pool"
n8: rectangle label:"Process Payment Request"
n9: diamond label:"Pool Exhausted?"
n10: rectangle label:"Queue with Timeout"
n7.handle(right) -> n8.handle(left) [label="Thread Available"]
n7.handle(bottom) -> n9.handle(top) [label="Check"]
n9.handle(right) -> n10.handle(left) [label="Yes"]
n9.handle(top) -> n8.handle(bottom) [label="No"]
}
StandardPool { # Standard Thread Pool (20 threads)
n11: rectangle label:"Shared Connection Pool"
n12: rectangle label:"Process API Request"
n13: diamond label:"Pool Exhausted?"
n14: rectangle label:"Return 503 Service Unavailable"
n11.handle(right) -> n12.handle(left) [label="Thread Available"]
n11.handle(bottom) -> n13.handle(top) [label="Check"]
n13.handle(right) -> n14.handle(left) [label="Yes"]
n13.handle(top) -> n12.handle(bottom) [label="No"]
}
BatchPool { # Batch Thread Pool (5 threads)
n15: rectangle label:"Rate-Limited Pool"
n16: rectangle label:"Process Batch Job"
n17: diamond label:"Pool Exhausted?"
n18: rectangle label:"Backpressure: Delay Retry"
n15.handle(right) -> n16.handle(left) [label="Thread Available"]
n15.handle(bottom) -> n17.handle(top) [label="Check"]
n17.handle(right) -> n18.handle(left) [label="Yes"]
n17.handle(top) -> n16.handle(bottom) [label="No"]
}
Pourquoi ce workflow ?
A single slow or failing dependency can consume all available threads or connections, starving healthy operations. The bulkhead pattern isolates workloads into separate resource pools—like watertight compartments in a ship—so that a failure in one pool cannot affect the availability of others.
Comment ça fonctionne
- Step 1: Incoming requests are classified by type: critical, standard, or batch.
- Step 2: Each category is routed to a dedicated thread pool with fixed capacity.
- Step 3: The critical pool (payments) has guaranteed resources that cannot be consumed by other workloads.
- Step 4: The standard pool handles regular API requests with a larger thread allocation.
- Step 5: The batch pool processes background jobs with rate limiting and lower priority.
- Step 6: When a pool is exhausted, requests are either queued with timeout or rejected with 503.
Alternatives
A single shared thread pool is simpler but vulnerable to noisy-neighbor problems. Kubernetes resource limits provide pod-level isolation. This template shows application-level bulkhead isolation for fine-grained workload protection.
Key Facts
| Template Name | Architecture d'isolation par cloison (Bulkhead) |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associé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 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 cellulaire avec routage géographique vers des cellules indépendantes et autonomes (US-East, EU-West), chacune avec sa propre passerelle, calcul, base de données, cache et file de messages, plus des services partagés pour la réplication inter-cellules et la configuration globale. Ce modèle représente le pattern d'architecture cellulaire utilisé par les systèmes hyperscale pour atteindre l'isolation du rayon d'impact, où les défaillances dans une cellule ne peuvent pas affecter les utilisateurs d'une autre. Clé pour les architectes concevant des systèmes nécessitant une disponibilité extrême et une isolation des pannes.
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.