Architecture
Diagramme d'architecture du pattern de vérification de santé avec sondes de load balancer, vérifications de santé approfondies vérifiant la base de données, le cache, le disque et l'état des dépendances, rotation automatique des instances et intégration d'alertes avec PagerDuty pour les échecs consécutifs. Ce modèle représente l'infrastructure de surveillance de santé qui permet des systèmes auto-réparateurs, où les instances défaillantes sont automatiquement retirées de la rotation et les équipes opérationnelles sont alertées. Clé pour construire des services prêts pour la production avec une observabilité appropriée.
Code FlowZap complet
LoadBalancer { # Load Balancer
n1: circle label:"Health Check Timer"
n2: rectangle label:"Send Health Probe"
n3: rectangle label:"Evaluate Response"
n4: diamond label:"Instance Healthy?"
n5: rectangle label:"Keep in Rotation"
n6: rectangle label:"Remove from Rotation"
n7: rectangle label:"Update Routing Table"
n1.handle(right) -> n2.handle(left) [label="Every 10s"]
n2.handle(bottom) -> ServiceA.n8.handle(top) [label="GET /health"]
n2.handle(bottom) -> ServiceB.n12.handle(top) [label="GET /health"]
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left) [label="200 OK"]
n4.handle(bottom) -> n6.handle(top) [label="Timeout/5xx"]
n5.handle(right) -> n7.handle(left)
n6.handle(right) -> n7.handle(left)
}
ServiceA { # Service A
n8: rectangle label:"Check Database Connection"
n9: rectangle label:"Check Redis Connection"
n10: rectangle label:"Check Disk Space"
n11: rectangle label:"Return Health Status"
n8.handle(right) -> n9.handle(left) [label="DB OK"]
n9.handle(right) -> n10.handle(left) [label="Cache OK"]
n10.handle(right) -> n11.handle(left) [label="Disk OK"]
n11.handle(top) -> LoadBalancer.n3.handle(bottom) [label="Status JSON"]
}
ServiceB { # Service B
n12: rectangle label:"Check API Dependencies"
n13: rectangle label:"Check Message Queue"
n14: rectangle label:"Check Memory Usage"
n15: rectangle label:"Return Health Status"
n12.handle(right) -> n13.handle(left) [label="APIs OK"]
n13.handle(right) -> n14.handle(left) [label="Queue OK"]
n14.handle(right) -> n15.handle(left) [label="Memory OK"]
n15.handle(top) -> LoadBalancer.n3.handle(bottom) [label="Status JSON"]
}
Alerting { # Alerting System
n16: rectangle label:"Monitor Health Trends"
n17: diamond label:"Consecutive Failures?"
n18: rectangle label:"Send PagerDuty Alert"
n19: rectangle label:"Log Health Metric"
n16.handle(right) -> n17.handle(left)
n17.handle(right) -> n18.handle(left) [label="3+ Failures"]
n17.handle(bottom) -> n19.handle(top) [label="Below Threshold"]
n7.handle(bottom) -> Alerting.n16.handle(top) [label="Status Change"]
}
Pourquoi ce workflow ?
Load balancers that route traffic to unhealthy instances cause user-facing errors. Deep health checks verify not just that the process is running, but that all critical dependencies (database, cache, disk, external APIs) are functioning—enabling automatic instance rotation and proactive alerting before users are affected.
Comment ça fonctionne
- Step 1: The load balancer sends periodic health probes (GET /health) to each service instance.
- Step 2: Each service checks its database connection, cache connectivity, disk space, and memory usage.
- Step 3: A JSON health status is returned with individual component statuses.
- Step 4: Healthy instances remain in the load balancer rotation; unhealthy ones are removed.
- Step 5: The alerting system monitors health trends and fires alerts on consecutive failures.
- Step 6: PagerDuty notifications are sent when failure thresholds are exceeded.
Alternatives
Simple TCP health checks only verify the process is listening. Liveness probes in Kubernetes restart unhealthy pods. Readiness probes control traffic routing. This template shows deep application-level health checks with alerting integration.
Key Facts
| Template Name | Architecture du pattern de vérification de santé |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.
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.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.