Monolith to Microservices: Strangler Fig Pattern on AWS Fargate
Incrementally decomposing a monolithic application into Dockerized microservices deployed on Amazon ECS with AWS Fargate and ALB path-based routing.
1. Business Problem & Context
A fintech SaaS company maintained a 10-year-old monolithic Rails application. Deploying a minor bug fix to the authentication code required re-testing and deploying the entire 2-gigabyte codebase. A single memory leak in the billing module crashed the entire customer-facing platform.
2. Requirements & Constraints
- Zero-Risk Migration: Avoid a high-risk “Big Bang” rewrite; incrementally strangle features out of the monolith.
- No Server Maintenance: The team had no dedicated Kubernetes/SRE engineers and needed serverless container management.
- Path-Based Ingress: Transparently route traffic between legacy monolith and new microservices without breaking API URLs.
3. Architecture Overview & Data Flow
Interactive Architecture Diagram (Use controls to zoom & pan)
- Identify Boundary: Isolated the
/api/authdomain as the first candidate for extraction. - Build Containerized Service: Packaged the new lightweight Node.js/Go service into a Docker image and pushed to Amazon ECR.
- Deploy to ECS Fargate: Created an ECS Service with Target Tracking autoscaling (50% CPU).
- Shift ALB Rule: Updated the ALB listener rule to route
/api/auth/*to the Fargate Target Group while keeping all other traffic on the legacy monolith.
4. AWS Services Used & Rationales
AWS Services Architecture Rationale
Concrete reasons why these specific services were chosen over alternatives
| Service | Category | Architectural Rationale ("Why this service?") |
|---|---|---|
| Amazon ECS with AWS Fargate | Containers | Runs containers with task-level CPU and memory isolation without managing worker node EC2 VMs. |
| Application Load Balancer | Networking | Provides path-based routing rules that decouple external URLs from internal service locations. |
| Amazon ECR | Containers | Stores encrypted container images with automated Clair vulnerability scanning. |
5. Key Design Trade-offs
Architecture Decision & Trade-Off Matrix
Evaluating alternative approaches under real-world constraints
Big Bang Rewrite to Amazon EKS (Kubernetes)
- + Complete Kubernetes feature set
- − High operational complexity
- − High risk of 6-12 month delivery delay
- − Requires dedicated SREs
Incremental Strangler Fig on ECS Fargate (Chosen)
✓ Chosen Design- + Zero downtime migration
- + Zero node management
- + Continuous value delivery every sprint
- − Temporary dual-running costs for monolith and microservices
6. Implementation Highlights
Terraform ALB Listener Rule Path Routing Pattern
resource "aws_lb_listener_rule" "auth_microservice" {
listener_arn = aws_lb_listener.front_end.arn
priority = 10
action {
type = "forward"
target_group_arn = aws_lb_target_group.auth_fargate.arn
}
condition {
path_pattern {
values = ["/api/auth/*", "/oauth/*"]
}
}
}7. Results & Key Metrics
- Release Speed: Feature deployment frequency increased from monthly to multiple times daily.
- Blast Radius Containment: Payment processing outages zeroed out due to complete container process isolation.
8. Key Architectural Takeaways
Strangler Fig Law: Never attempt a 100% ground-up rewrite of a production monolith. Use ALB path routing and containerized Fargate tasks to extract one domain at a time.
