Strangler Fig Pattern Diagram: Migrating a Monolith to Microservices (2026)
How to create a strangler fig pattern architecture diagram for monolith-to-microservices migrations. Covers the façade layer, transform-coexist-eliminate phases, and comparison with big-bang rewrites — with AI prompt templates.
R
Ryan·Senior AI Engineer
The strangler fig pattern is an incremental migration strategy for replacing a legacy monolith with microservices by routing specific capabilities to new services one at a time, without a risky all-at-once rewrite. Named after the strangler fig tree that grows around an existing tree and gradually replaces it, the pattern introduces a façade layer (API gateway or reverse proxy) that intercepts traffic and routes it either to the legacy monolith or to the new services — allowing the two to coexist safely during the migration.
A strangler fig architecture diagram is essential for communicating the migration state to engineering teams, product stakeholders, and leadership: it shows what has been extracted, what remains in the monolith, and the routing logic that keeps the system working throughout the transition.
The three phases of strangler fig migration
- Transform: Build the new microservice alongside the monolith. The new service implements the same capability (e.g., authentication, order processing) as the monolith module. No traffic is redirected yet. The diagram shows two parallel systems.
- Coexist: The façade layer is introduced. Some traffic (often a small percentage, or traffic from a specific region or customer segment) is routed to the new service. The monolith handles the rest. Both systems may need to share a database during this phase — use the shared database anti-pattern consciously and with a plan to separate schemas.
- Eliminate: 100% of traffic for the extracted capability routes to the new microservice. The monolith code for that module is deleted. Repeat for the next capability until the monolith is fully decommissioned.
Core components of a strangler fig diagram
- The façade / strangler facade: An API gateway, reverse proxy (NGINX, Envoy), or BFF (Backend for Frontend) that sits between clients and both the monolith and the new services. Routing decisions — which requests go where — live here. This is the most important component to diagram clearly.
- The legacy monolith: The existing application, shown as a single block. Modules that have been extracted are crossed out or shaded differently to indicate they are no longer active in the monolith.
- Extracted microservices: Each new service built to replace a monolith module, with its own database and deployment lifecycle.
- Shared data store (temporary): During coexistence, the new service and the monolith may share a database. Annotate this as a temporary state with a planned migration date — shared databases are a migration risk that should be visible on the diagram.
- Routing rules: Annotate the routing logic on each façade → destination arrow: path-based routing (/api/auth/* → Auth Service), header-based routing (X-Beta-User → new service), or percentage-based traffic splitting.
Prompt examples for strangler fig diagrams
Phase 1 — baseline monolith (before migration)
"A Rails monolith serving a B2B SaaS application. All traffic enters through a single Nginx reverse proxy. The monolith handles: user authentication (Devise), subscription billing (Stripe webhooks), order management, product catalog, reporting, and email notifications. Everything shares one PostgreSQL database. The monolith is deployed on Heroku as a single Dyno. Background jobs run via Sidekiq with a Redis queue. We want to begin extracting the Auth and Billing modules."
Phase 2 — strangler fig coexistence (mid-migration)
"Strangler fig migration in progress: a Kong API Gateway acts as the façade. Requests to /api/auth/* route to a new standalone Auth Service (Node.js, JWT, its own PostgreSQL database). Requests to /api/billing/* route to a new Billing Service (Python, Stripe SDK, its own PostgreSQL). All other requests (/api/orders/*, /api/products/*, /api/reports/*) still route to the legacy Rails monolith. The Auth Service and monolith temporarily share the users table via a read replica — migration to separate schemas planned for Q3. Kong handles JWT validation for all downstream services. Both environments are deployed on AWS ECS Fargate."
Phase 3 — final state (monolith eliminated)
"Post-strangler fig migration: the monolith is decommissioned. Kong API Gateway routes to five independent microservices: Auth Service, Billing Service, Order Service, Product Catalog Service, and Reporting Service. Each has its own PostgreSQL database. Background jobs are distributed across per-service SQS queues with Lambda workers. A shared event bus (AWS EventBridge) handles cross-service events (OrderPlaced, UserUpgraded). All services run on ECS Fargate with auto-scaling. No shared database — each service owns its data exclusively."
Strangler fig vs. alternative migration strategies
| Strategy | Risk level | Migration time | Rollback | Best for |
|---|---|---|---|---|
| Strangler fig | Low | Months to years | Easy (reroute façade) | Most production systems |
| Big bang rewrite | Very high | Months (parallel) | Hard (maintain two codebases) | Small apps, greenfield rewrites |
| Branch by abstraction | Low-Medium | Weeks to months | Easy (toggle abstraction) | In-process module replacement |
| Parallel run | Low | Weeks | Easy (stop shadow traffic) | Validation before cutover |
What to annotate on a strangler fig diagram
- Migration phase label: Add a clear "Current state: Phase 2 of 3 — Auth and Billing extracted" note on the diagram so reviewers immediately understand where in the migration they are
- Routing rules on the façade: Show the routing decision logic — path patterns, headers, or percentage splits — on each arrow from the façade. This is the most-reviewed part of the diagram.
- Shared database risk: Mark any temporary shared database connection with a warning annotation and planned removal date. Shared data stores are the most common failure point in strangler fig migrations.
- Eliminated modules: Show extracted modules with a strikethrough or muted color in the monolith block — this visually communicates progress and prevents confusion about which version handles each capability.
- Rollback path: Include a dashed arrow showing how traffic would be re-routed back to the monolith if the new service fails — this is the key safety guarantee of the strangler fig pattern.
Related guides: monolith to microservices migration, microservice architecture patterns, API gateway architecture, and saga pattern diagrams.
Ready to try it yourself?
Start Creating - Free