Skip to content
Back to case studies
NDA-safeMigration2022

E-Commerce Serverless

Peak-hour monolith failures + inflated EC2 → 5M+ orders/mo, P99 <200ms, ~30% infra reduction.

Role
Senior Software Engineer
Context
Retail / E-Commerce
Duration
8 months
Team
4 engineers + 1 architect (me)

Tech stack

  • Node.js
  • Go
  • Kafka
  • ECS/EKS
  • Kubernetes
  • Redis
  • MySQL
  • Terraform
  • GitHub Actions
Executive summary

Business problem and production context.

Business problem

Legacy PHP monolith on EC2 couldn't handle peak-hour traffic spikes during promotions. Deployments were risky, costs were inflated from overprovisioned instances, and the system suffered from cascading failures under load.

Architecture decision

Led migration using the Strangler Fig pattern, incrementally routing traffic from the monolith to event-driven microservices built with Node.js, Go, and Kafka on ECS/EKS. Implemented blue-green deployments and auto-scaling on Kubernetes for zero-downtime releases.

awsAWS Account / KFC prodRequestResponseORDER INGRESSORDER PROCESSING PIPELINESTATE + EVENTS123456789CloudFrontstatic + cacheALBblue/green routingECS / EKSGo + Node servicesKafkaorder eventsLambdapromo + pricingSQSretry + DLQLambdafulfillmentDynamoDBorder stateRDS Auroracatalog read replicasElastiCachesession + cartCROSS-CUTTING: Blue/green deploys · Auto-scaling on K8s · Spend per promo capped · Per-tenant rate limits
What Rahul owned

The useful proof is the decision surface, not only the result number.

These are the parts of the work that show production judgment: ownership, constraints, rollback, cost, and observability.

Owned scope

  • Migration path from fragile monolith endpoints toward independently deployable order services
  • Traffic, latency, rollback, and event-flow decisions for peak commerce load
  • Operational shape for blue-green releases and queue/consumer monitoring

Evidence artifacts

5M+ monthly orders supportedP99 latency improvementStrangler migrationBlue-green release pathQueue-lag monitoring
Constraints

What would fail first?

Every project has constraints. The useful work is naming them early enough that rollback, cost, and ownership are designed before an incident.

Peak traffic

Promotion traffic created sharp spikes where synchronous paths and overprovisioned compute both hurt.

Revenue path

Checkout and order flows had to migrate without creating customer-visible downtime.

Mixed stack

The migration needed to coexist with a legacy PHP monolith during staged cutover.

Decision table

Trade-offs accepted on purpose.

Option
Decision
Reason
ECS/EKS vs pure Lambda
Chose containers for long-running order processing workflows and predictable latency
ECS/EKS vs pure Lambda: Chose containers for long-running order processing workflows and predictable latency.
Kafka vs SQS
Kafka selected for high-throughput event streaming with replay capability across 5M+ monthly orders
Kafka vs SQS: Kafka selected for high-throughput event streaming with replay capability across 5M+ monthly orders.
Blue-green vs canary
Blue-green chosen for simpler rollback during critical commerce operations
Blue-green vs canary: Blue-green chosen for simpler rollback during critical commerce operations.
Risk table

Production risks and how they were controlled.

Risk
Mitigation
Owner
Cascading order failures
Separated order lifecycle events and monitored consumer lag before expanding traffic.
Order platform owner
Bad release during checkout traffic
Used phased routing and blue-green rollback instead of big-bang replacement.
Release owner
Overprovisioned infrastructure stayed hidden
Mapped traffic hotspots and autoscaling behavior before committing to the new shape.
Platform + finance
Implementation approach

Small steps, visible changes, fewer surprises.

  1. 01

    Audited the PHP monolith and mapped all 47 API endpoints, identifying 12 high-traffic hotspots causing 80% of the latency issues.

  2. 02

    Implemented Strangler Fig pattern, routing traffic endpoint-by-endpoint from monolith to new Node.js/Go microservices behind an API Gateway.

  3. 03

    Built Kafka-based event bus for order lifecycle events (placed → confirmed → dispatched → delivered), decoupling services from synchronous calls.

  4. 04

    Deployed on ECS/EKS with Kubernetes auto-scaling tied to order queue depth, handling 3x traffic spikes during promotions without manual intervention.

  5. 05

    Ran both systems in parallel for 6 weeks, comparing response times and error rates before fully cutting over.

Result

Before and after.

P99 Latency
2.8s
<200ms
Monthly Infra Cost
baseline
~30% lower
Deploy Frequency
1x/week (manual)
4x/day (automated)
Peak Capacity
~500 req/s
5,000+ req/s

Rollback path

The strangler path kept old and new services running in parallel so endpoint rollback stayed possible during migration.

Cost considerations

Cost reduction came from removing overprovisioned instances and scaling around real order traffic rather than peak fear.

Observability notes

P99 latency, order error rate, queue/consumer lag, deploy health, and checkout-path alarms mattered more than generic dashboard count.

Related services

Forward Deployed AI EngineeringAWS Production Architecture ReviewGenAI / RAG Production Readiness

Have a similar production problem?

Send the current architecture, bill concern, deployment pain, or GenAI reliability issue. I will help you find the first real bottleneck.

Rahul LadumorBook a production reviewContact form