How UrbanCart Rebuilt Its Platform in 12 Weeks: From Legacy Monolith to AWS Microservices

Overview

UrbanCart is a mid-sized consumer electronics marketplace operating across India, serving approximately 1.8 million registered users and 12,000 active merchants. Before the migration described in this case study, the entire platform—catalog, cart, checkout, payments, inventory, order tracking, and notifications—ran as a single 140,000-line Node.js monolith deployed on a pair of EC2 instances behind a classic load balancer. The architecture had served the company well through four years of steady growth, but by late 2025 it was beginning to show the unmistakable signs of strain that technical debt inherits when left unattended.

The engineering team, then comprising 17 full-time developers, made the decision to pursue a full microservices migration in early January 2026. Twelve weeks later, UrbanCart was running six decoupled services on Amazon ECS, backed by RDS Aurora, Redis Cluster, SNS/SQS, and CloudFront—operating at 40% lower infrastructure cost per transaction while absorbing a 280% spike in peak traffic without a single deployment-related incident. This case study reconstructs that journey in detail.

The Challenge

The immediate catalyst for the migration was the impending Black Friday–Christmas shopping window. In November 2025, UrbanCart experienced a cascading failure during a promotional sale: the monolith's database connection pool exhausted under sustained 3,500 concurrent users, bringing down cart, checkout, and inventory simultaneously. Recovery took 47 minutes. Revenue lost in that window was later estimated by the finance team at approximately ₹14 lakhs.

But the problem extended beyond a single incident. Daily deployments had become a source of genuine anxiety—any push to the monolith required full regression testing across all modules, with a mandatory 90-minute maintenance window. Hotfixes to one subsystem risked introducing regressions in unrelated domains. New engineers took an average of six weeks to become productive on the codebase. And the monolith's cold-start time for new feature development had grown so long that the product team had begun depriororitizing agreed-upon roadmap items simply because engineering couldn't deliver them in a practical timeline.

Goals

The migration program—internally codenamed "Project Skyline"—was scoped around four explicit, measurable goals before a single line of new code was written:

Resilience under load: Achieve 99.9% uptime during peak promotional windows with graceful degradation. A failure in the payments service, for example, must not take down product recommendations or search.

Deployment independence: Enable any service to be deployed without requiring coordination across the entire team. Target time-to-production for low-risk changes: under two hours from PR merge to live.

Scalability by service: The checkout service, historically the most resource-intensive component, must scale independently of the catalog or notification services—reducing wasteful overprovisioning.

Minimal disruption: The migration must not require a full platform downtime event. All changes must be deployed incrementally, preserving the live production environment throughout.

Approach: Strangler Fig Architecture

Rather than attempting a "big bang" rewrite—a strategy that has destroyed more engineering teams than it has saved—the team adopted the Strangler Fig pattern: new services would be built alongside the monolith, feature-by-feature, with a reverse proxy (AWS API Gateway) routing traffic to either the new service or the legacy system depending on the feature being accessed. This allowed incremental migration with the ability to roll back instantly to the monolith path at any point.

The six core services were identified, prioritized, and sequenced based on business impact and technical complexity:

1. Catalog & Search — Elasticsearch-backed product search, category navigation, product detail.
2. Cart & Wishlist — Session-backed cart, wishlist management, merge on login.
3. Checkout & Payments — Address entry, order summary, payment gateway orchestration.
4. Inventory — Stock tracking, low-stock alerts, reservation and release.
5. Order Management — Order lifecycle, status transitions, history, returns.
6. Notifications — Email, SMS, and in-app push via SNS.

Implementation

Implementation was structured in four one-week sprints (plus a planning week) for a total of five weeks of intensive delivery, followed by two weeks of soak testing and performance validation before the final cutover.

Week 1 – Foundation and Infrastructure as Code

The first week was entirely infrastructure work: no features were built. The team used Terraform to define all AWS resources as code, committing the configuration to the same repository that held the application stack. This created an auditable, reproducible infrastructure definition that could spin up identical staging environments in under 20 minutes.

Key infrastructure decisions made this week included: ECS Fargate for container orchestration (eliminating the overhead of managing EC2 fleets), Aurora PostgreSQL 15 for the primary data store, ElastiCache Redis for session storage and caching hot product data, and CloudFront in front of API Gateway for global edge routing.

Weeks 2–3 – Catalog and Cart Services

The catalog service was the natural first production target: it is read-heavy (over 85% read traffic), had the simplest data model, and was responsible for the largest share of monolith CPU usage during peak load. A full-text search index was built using Elasticsearch with OpenSearch Service, with a CDC (Change Data Capture) pipeline from Aurora to OpenSearch using Debezium. Product detail pages were served from a Redis cache with a 15-minute TTL, warming on application startup for the most-viewed 5,000 SKUs.

The cart service was more complex because it required session affinity and merge logic when anonymous users logged in. The team adopted Redis Hash structures to store cart data, enabling O(1) item lookup and atomic increment/decrement operations for quantity changes. The cart service communicates with the catalog service via gRPC for product metadata lookups, keeping the REST gateways free of cross-service synchronous blocking calls.

Both services were instrumented from day one: OpenTelemetry traces were captured with AWS X-Ray as the backend, and structured logs were shipped to CloudWatch Logs Insights with a consistent JSON schema across all services. This instrumentation effort paid enormous dividends during performance tuning in later sprints.

Weeks 4–5 – Checkout, Payments, and Inventory

Checkout was the highest-risk migration and therefore executed with the most deliberate testing rigour. The team built a feature flag system using AWS AppConfig that allowed routing individual users—or percentage-bucketed traffic slices—between the monolith checkout flow and the new service, enabling canary testing with live shoppers rather than synthetic test data.

Payment routing was implemented as a resilient orchestration layer: the service attempts the primary payment gateway (Razorpay) with a 4-second timeout, falls back to a secondary provider (Cashfree) on timeout, and surfaces a graceful offline-payment option if both integrations fail. Eventual consistency is maintained through SNS/SQS sagas, so a payment success event reliably triggers inventory deduction and order creation even under partial system load.

The inventory service adopted a pessimistic-lock pattern for high-demand SKUs to prevent overselling, with a compensating release transaction triggered if a checkout flow is abandoned mid-purchase. Inventory levels are cached in Redis with a 10-second TTL, reducing read pressure on Aurora during flash sales.

Week 6 – Order Management and Notifications, Migration Cutover

The final two production services—order management and notifications—were implemented in week 6. Order management handles the complete order lifecycle through a state machine driven by Amazon SNS event notifications. When an order transitions to "shipped," an event is published to SNS, which fans out to the notifications service and an analytics pipeline in parallel without coupling the two downstream consumers.

Cutover to the new architecture was executed on a Saturday night with a two-hour maintenance window—allowing the team to drain live sessions from the monolith, point the API Gateway routing at the new services, and monitor for anomalies before re-opening the platform to all users. Over the following 48 hours, the team ran in "hypercare" mode with all senior engineers on call. Four small regressions were found and patched within hours; none caused customer-facing downtime.

Results

The migration delivered outcomes that exceeded every pre-defined goal. Below is a breakdown of the most significant results.

Uptime and traffic handling. UrbanCart ran through its first peak event post-migration—New Year's Eve sales—with zero platform downtime. The checkout service scaled from 200 task replicas at baseline to 2,400 under peak load, driven automatically by ECS Service Auto Scaling responding to CPU utilization. The latency p99 improved from 820ms on the monolith to 210ms on the new service mesh.

Deployment velocity. Average time-to-production for feature changes dropped from 22 days (constrained by the monolith's release cycle) to approximately 72 hours across all six services. Deployment frequency increased 6x, with zero production incidents attributable to deployment changes in the following three months.

Operating cost. Fargate's serverless container model, combined with the ability to scale individual services independently, reduced overall infrastructure spend by approximately 38% compared to the prior fixed-infrastructure arrangement—despite handling nearly 3x the transaction volume.

Engineering experience. New-hire ramp-up time for contributing to service code fell from an average of six weeks to two weeks, driven by smaller, focused codebases and the shared infrastructure documentation built during the IaC phase of the project.

Key Metrics Summary

Metric	Before	After	Change
Platform uptime	99.1%	99.94%	▲ +0.84pp
P99 latency	820ms	210ms	▼ 74%
Deploy frequency	2/month	12/month	▲ 6x
Mean time to recovery	47min	4.2min	▼ 91%
Infrastructure cost/transaction	₹4.12	₹2.55	▼ 38%
New hire ramp time	6 weeks	2 weeks	▼ 67%

Lessons Learned

The most important lesson was also the most unexpected: the hardest part of the migration was not the technical work, but the organizational coordination required to run two systems in parallel for five weeks. Decision ownership across the old and new flows blurred disputes on several occasions, and having a single migration lead with formal authority to adjudicate routing decisions was worth more than the additional architecture-review hours invested in data contracts.

A second lesson worth emphasizing: invest in event schemas early. The team drafted and versioned event payloads for all inter-service communication—order.created, payment.succeeded, inventory.reserved—before writing a single consumer. This eliminated an entire class of data compatibility issues during the integration phase that teams in earlier migrations had lost weeks to.

Finally, monitoring coverage was never perfect, and that is acceptable. The team accepted 80% instrumentation coverage at launch rather than delaying the cutover to achieve 100%. The missing 20% was filled incrementally over the following two months, without a single incident arising from an uninstrumented path. Perfect monitoring is the enemy of shipping—even for a high-stakes platform migration.

Conclusion

UrbanCart's migration from monolith to microservices on AWS was completed in 12 weeks with zero customer-facing downtime, under budget, and delivering results that exceeded every stated goal. The case demonstrates that with a disciplined Strangler Fig approach, feature-flagged canary routing, and an unwavering commitment to infrastructure-as-code discipline, even a legacy platform carrying significant revenue risk can be rearchitected without a single moment of downtime.

The most honest observation is perhaps this: the engineering team shipped the last service faster than expected, and the new platform has already quietly outlasted the original monolith in terms of expected longevity—a statistic the original architects never could have predicted in January 2026.