Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.
Full FlowZap Code
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"]
}
Why This 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.
How It Works
- 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 | Microservices Strangler Fig Migration Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A service discovery architecture diagram with Consul or Eureka registry, client-side load balancing, health check heartbeats, and automatic instance registration and deregistration. This template visualizes how microservices dynamically locate each other without hardcoded endpoints, enabling elastic scaling and self-healing infrastructure. Key for platform teams building resilient service-to-service communication.