Modernizing Monolithic APIs with Amazon ECS: From Single Node to Scalable Microservices

Challenge

TargetBay is a marketing automation SaaS provider whose core platform serves thousands of e-commerce merchants via RESTful APIs. The entire application stack — NGINX, PHP-FPM-based APIs, batch processing, and scheduled jobs — was deployed on a single c5.2xlarge EC2 instance.

This monolithic architecture created compounding operational risks:

• Monolithic Single Node: All application components shared a single compute instance, meaning any failure or resource spike affected every workload simultaneously.
• Resource Contention: Traffic spikes triggered out-of-memory (OOM) events, crashing services and causing frontend downtime for merchants relying on real-time API responses.
• Limited Scalability and Fault Tolerance: The only scaling option was vertical (upgrading the instance size), which required downtime and offered no redundancy against instance failure.
• Slow Deployment Cycle: Releasing updates to any component risked disrupting live traffic across the entire platform, forcing cautious, infrequent deployments.

Solution

FactualMinds decomposed TargetBay’s monolithic application into independently deployable microservices running on Amazon ECS, backed by a cost-optimized compute layer and modern traffic management.

Microservice Decomposition:

• Converted each major component — public-api, jobs-processor, and admin-api — into separate Dockerized microservices with independent lifecycles and resource profiles.

ECS Cluster and Compute Optimization:

• Created an ECS Cluster backed by an Auto Scaling Group of c5.large EC2 instances
• Enabled a Spot and On-Demand instance mix to optimize compute spend without sacrificing availability
• Attached ECS Capacity Providers for dynamic container host scaling based on cluster utilization

Traffic Management:

• Deployed an Application Load Balancer with path-based routing to direct traffic to the appropriate service:
  • /api/v1/* routed to public-api
  • /jobs/* routed to jobs-processor
• Configured health checks for each target group to enable zero-downtime rolling deployments

API Gateway and Security:

• Integrated Amazon API Gateway with throttling at 100 requests per second, IAM-based authentication, and AWS WAF for request filtering

Auto Scaling and Observability:

• Configured ECS Service Auto Scaling with per-service policies that trigger scaling at greater than 60% CPU utilization
• Built CloudWatch Dashboards tracking CPU, memory, request latency, and error rates across all services

AWS Services Used

• Amazon ECS (EC2 Launch Type) — Container orchestration for microservices
• EC2 Auto Scaling Group — Dynamic compute capacity for ECS cluster hosts
• ECS Capacity Providers — Automated container placement and host scaling
• Application Load Balancer — Path-based routing and health-checked traffic distribution
• Amazon API Gateway — Throttling, authentication, and WAF integration
• Amazon CloudWatch — Monitoring dashboards, alarms, and metrics
• AWS IAM — Fine-grained access control across services

Results

The migration from a monolithic single-node deployment to a microservices architecture on ECS delivered measurable improvements across reliability, cost, and delivery speed:

• Zero-downtime deployments through rolling updates with health-checked target groups, eliminating the risk of service disruption during releases
• Independent microservice scaling allowing each component to scale based on its own resource demands rather than over-provisioning shared compute
• Reduced compute costs by leveraging Spot instances for fault-tolerant workloads alongside On-Demand instances for critical services
• Faster release cycles as teams could deploy changes to individual services without coordinating full-stack releases
• Improved fault tolerance with no single point of failure — individual service failures are isolated and auto-recovered without impacting the broader platform