Scaling a high-traffic microservices backend on AWS

The problem

The system relied heavily on the primary database for high-volume reads and on synchronous processing.

As traffic grew, the database was becoming the likely bottleneck, and application capacity was fixed.

Architecture: before → after

What I did

• Split the backend into roughly 20 services running on ECS behind an Application Load Balancer, connected through private DNS.
• Configured ECS autoscaling on CPU / memory at around a 60% threshold so capacity follows traffic.
• Moved frequently read data into Redis so hot paths no longer hit PostgreSQL directly.
• Pushed non-critical work onto SQS queues processed by workers, with a dead-letter queue for failed jobs.
• Added CloudWatch metrics and alarms with SNS notifications for operational visibility.

How I led it

• When the team had to prepare the backend for roughly 10x traffic growth, I broke the problem down into parts the team could own.
• Aligned the team on one approach before implementation instead of letting each service solve scaling differently.

Outcome

• Production traffic in the thousands of requests per second (peaks below 10K req/s), served by an autoscaled fleet.
• Direct read pressure on PostgreSQL reduced by serving hot data from Redis.
• Traffic spikes absorbed by autoscaling and queues instead of a fixed fleet.