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.
Code FlowZap complet
GlobalRouter { # Global Router
n1: circle label:"User Request"
n2: rectangle label:"Geographic Routing"
n3: diamond label:"User Cell Assignment?"
n4: rectangle label:"Route to Cell A"
n5: rectangle label:"Route to Cell B"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="US-East"]
n3.handle(bottom) -> n5.handle(top) [label="EU-West"]
n4.handle(bottom) -> CellA.n6.handle(top) [label="Forward"]
n5.handle(bottom) -> CellB.n12.handle(top) [label="Forward"]
}
CellA { # Cell A (US-East)
n6: rectangle label:"Cell Gateway"
n7: rectangle label:"Compute Layer"
n8: rectangle label:"Cell Database"
n9: rectangle label:"Cell Cache"
n10: rectangle label:"Cell Message Queue"
n11: circle label:"Cell Response"
n6.handle(right) -> n7.handle(left) [label="Process"]
n7.handle(right) -> n8.handle(left) [label="Read/Write"]
n7.handle(bottom) -> n9.handle(top) [label="Cache"]
n7.handle(bottom) -> n10.handle(top) [label="Async"]
n8.handle(right) -> n11.handle(left)
}
CellB { # Cell B (EU-West)
n12: rectangle label:"Cell Gateway"
n13: rectangle label:"Compute Layer"
n14: rectangle label:"Cell Database"
n15: rectangle label:"Cell Cache"
n16: rectangle label:"Cell Message Queue"
n17: circle label:"Cell Response"
n12.handle(right) -> n13.handle(left) [label="Process"]
n13.handle(right) -> n14.handle(left) [label="Read/Write"]
n13.handle(bottom) -> n15.handle(top) [label="Cache"]
n13.handle(bottom) -> n16.handle(top) [label="Async"]
n14.handle(right) -> n17.handle(left)
}
SharedServices { # Shared Services (Cross-Cell)
n18: rectangle label:"Global Config Service"
n19: rectangle label:"Cross-Cell Replication"
n20: rectangle label:"Monitoring and Alerting"
n18.handle(right) -> n19.handle(left) [label="Sync Config"]
n19.handle(top) -> CellA.n8.handle(bottom) [label="Replicate"]
n19.handle(top) -> CellB.n14.handle(bottom) [label="Replicate"]
n19.handle(right) -> n20.handle(left) [label="Health"]
}
Pourquoi ce workflow ?
Traditional multi-region deployments share databases and services across regions, meaning a failure in one component can affect all users globally. Cell-based architecture creates fully independent, self-contained cells where each cell serves a subset of users—limiting the blast radius of any failure to only the users in that cell.
Comment ça fonctionne
- Step 1: A global router assigns users to cells based on geographic location or account ID.
- Step 2: Each cell contains its own gateway, compute, database, cache, and message queue.
- Step 3: Cells operate independently—a failure in Cell A does not affect Cell B.
- Step 4: Shared services handle cross-cell concerns like global configuration and monitoring.
- Step 5: Cross-cell replication synchronizes data for disaster recovery.
- Step 6: New cells can be added to handle growth without affecting existing cells.
Alternatives
Multi-region active-active shares resources and has larger blast radius. Single-region with failover has longer recovery times. This template shows the cell architecture used by hyperscale systems like AWS and Azure.
Key Facts
| Template Name | Architecture cellulaire (Cell-Based) |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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.
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.