Architecture
Design Strangler Fig Pattern
The strangler fig pattern incrementally replaces a monolith with microservices by routing traffic through a facade. New features are built as microservices; existing features are migrated gradually.
- Problem — Monolith-to-migration is risky (big bang)
- Solution — Incremental migration via facade routing
- Metaphor — New services "strangle" the monolith over time
The strangler fig pattern turns a risky big-bang migration into a safe, gradual evolution.
What Is the Strangler Fig Pattern?
DfStrangler Fig Pattern
Named after the strangler fig tree that grows around a host tree and eventually replaces it. The pattern wraps the monolith with a facade (API gateway) that routes requests to either the monolith or new microservices. Over time, more routes point to microservices until the monolith is decommissioned.
Migration Phases
Facade Routing
DfAPI Gateway Facade
The facade (API Gateway) sits in front of the monolith and microservices. It routes requests based on URL paths, headers, or feature flags. During migration, the facade gradually shifts traffic from monolith to new services.
Routing Rule
Here,
- =Boolean flag for migration status
Migration Strategies
1. Branch by Abstraction
Introduce an abstraction layer over the monolith's interface. Implement the new microservice behind this abstraction. Switch between monolith and service using feature flags. This allows A/B testing and gradual rollout.
2. Parallel Run
Run both monolith and new service in parallel. Compare outputs. When the service matches the monolith, switch traffic. This provides safety through verification.
3. Event Interception
Capture events from the monolith. Feed them to new services. This allows new services to build their own data models without modifying the monolith.
Data Migration
DfDual Write During Migration
During migration, both monolith and new service may write to the same data. Use the outbox pattern to synchronize. The monolith writes to its database; the new service reads from CDC. Over time, the new service owns its data.
Practice Exercises
- Design: How would you migrate the user authentication module from a monolith to a microservice using the strangler fig pattern?
- Routing: Design a facade that routes traffic based on user segments (beta users go to new service).
- Data: How do you handle database schema differences between monolith and new service during migration?
- Rollback: Design a rollback strategy if the new service fails in production.
Key Takeaways:
- Strangler fig enables incremental migration without big-bang risk
- Facade routing (API Gateway) directs traffic to monolith or new services
- Feature flags control which users see new services
- Parallel run validates new services against monolith behavior
- Data migration uses outbox pattern and CDC for synchronization
What to Learn Next
-> Sidecar Pattern Service mesh for new services.
-> Outbox Pattern Data synchronization during migration.
-> Saga Pattern Distributed transactions in new services.
-> Sticky Sessions Session migration.
-> Circuit Breaker Resilience during migration.
-> Design Netflix Microservice architecture.