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.
Code FlowZap complet
Client { # Client
n1: circle label:"User Request"
n2: rectangle label:"Anti-Corruption Layer"
n3: rectangle label:"Receive Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Router.n5.handle(top) [label="Translate"]
n3.handle(right) -> n4.handle(left)
}
Router { # Strangler Fig Router
n5: rectangle label:"Inspect Request Path"
n6: diamond label:"Migrated Endpoint?"
n7: rectangle label:"Route to New Service"
n8: rectangle label:"Route to Legacy Monolith"
n9: rectangle label:"Log Migration Metrics"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n7.handle(bottom) -> NewServices.n10.handle(top) [label="Forward"]
n8.handle(bottom) -> Legacy.n14.handle(top) [label="Forward"]
n7.handle(right) -> n9.handle(left) [label="Track"]
n8.handle(right) -> n9.handle(left) [label="Track"]
}
NewServices { # New Microservices
n10: rectangle label:"Process in New Service"
n11: rectangle label:"New Service Database"
n12: rectangle label:"Publish Domain Event"
n13: rectangle label:"Return Response"
n10.handle(right) -> n11.handle(left) [label="Query"]
n11.handle(right) -> n12.handle(left) [label="Write"]
n12.handle(right) -> n13.handle(left)
n13.handle(top) -> Client.n3.handle(bottom) [label="New Response"]
}
Legacy { # Legacy Monolith
n14: rectangle label:"Process in Monolith"
n15: rectangle label:"Legacy Database"
n16: rectangle label:"Return Legacy Response"
n14.handle(right) -> n15.handle(left) [label="SQL"]
n15.handle(right) -> n16.handle(left) [label="Result"]
n16.handle(top) -> Client.n3.handle(bottom) [label="Legacy Response"]
}
Pourquoi ce workflow ?
Big-bang monolith rewrites fail 70% of the time due to scope creep, feature parity gaps, and business disruption. The strangler fig pattern enables incremental migration by routing traffic between the legacy monolith and new microservices, allowing teams to migrate one endpoint at a time with zero downtime and instant rollback capability.
Comment ça fonctionne
- Step 1: A routing layer (strangler fig router) is placed in front of the legacy monolith.
- Step 2: New features are built as microservices instead of adding to the monolith.
- Step 3: The router inspects each request path and decides whether to forward to the new service or the legacy system.
- Step 4: An anti-corruption layer translates between old and new data formats.
- Step 5: Migration metrics track the percentage of traffic handled by new services.
- Step 6: Legacy endpoints are retired once the new service is stable and fully tested.
Alternatives
Big-bang rewrites are risky and expensive. Running parallel systems without a router creates confusion. Branch-by-abstraction works for libraries but not for services. This template visualizes the proven incremental migration strategy.
Key Facts
| Template Name | Architecture de migration Strangler Fig pour microservices |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture DDD des contextes bornés avec les contextes Commande, Client, Expédition et Facturation connectés via une couche anti-corruption, un noyau partagé et une carte de contextes définissant les relations d'intégration. Ce modèle visualise les patterns stratégiques DDD pour décomposer des domaines complexes en contextes bornés autonomes qui communiquent par des événements d'intégration bien définis. Critique pour les architectes appliquant le Domain-Driven Design aux systèmes d'entreprise à grande échelle.
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 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.