From Legacy to Leaderboard: How a 12-Year-Old eCommerce Platform Achieved 340% Growth with Modern Architecture

# From Legacy to Leaderboard: How a 12-Year-Old eCommerce Platform Achieved 340% Growth with Modern Architecture ## Overview Founded in 2012, ElectroMart started as a single-store electronics retailer in Bengaluru with a modest online catalog of 200 products. By 2024, the company had grown into a multi-category marketplace serving 18 states across India, with over 50,000 SKUs, 2.3 million registered users, and a workforce of 420 employees. However, beneath this growth story lay a crumbling technological foundation that threatened to bring the entire operation to a halt. The original eCommerce platform, built on a monolithic LAMP stack and deployed on a single dedicated server, had served the company faithfully through its early years. But by 2022, the system was showing unmistakable signs of distress. Page load times had ballooned to 8-12 seconds during peak traffic. The checkout funnel was converting at less than 1.2%. Database connections were maxing out during festival sales. And the engineering team—down to just three developers—spent more time putting out fires than building new features. This case study documents the 18-month transformation journey that took ElectroMart from a legacy system on the brink to a modern, scalable platform capable of handling Black Friday-level traffic with ease. ## The Challenge ElectroMart's technical debt had accumulated over a decade of quick fixes, feature hacks, and organic growth. The monolith had become a tangled web of interdependencies where a change in the payment module could unexpectedly break the search functionality. The single-server architecture meant that every maintenance window translated directly into downtime. **Performance Bottlenecks:** The homepage and product listing pages were generated server-side with PHP, hitting the same MySQL database instance for every request. During high-traffic events like Diwali sales and Republic Day promotions, the database would exhaust its connection pool, causing cascading failures across the entire site. **Scalability Constraints:** The platform could not scale horizontally. Adding more web servers didn't help because they all pointed to the same overloaded database. Auto-scaling was impossible, and the team relied on manual provisioning during expected traffic spikes. **Developer Velocity:** With only three backend developers maintaining a 100,000-line codebase, the team averaged one production deployment per quarter. Any urgent bug fix required a full regression test of the entire system. New feature development had all but stopped, giving competitors a significant advantage. **Inventory Accuracy:** The inventory system was updated in batch every 15 minutes. In a market where competitors could fulfill orders within two hours, ElectroMart's outdated stock levels led to frequent overselling, customer complaints, and a rising rate of order cancellations. **Mobile Experience:** The mobile site was an afterthought—a scaled-down version of the desktop pages. With 68% of India's eCommerce traffic coming from mobile devices, ElectroMart was hemorrhaging customers at the first interaction. Mobile conversion rates were a dismal 0.8%. **Security Posture:** The platform was running on PHP 7.2, which reached end-of-life in November 2021. Critical security patches were no longer available, and the PCI-DSS audit flagged the payment processing module as high-risk. Compliance certification was at risk of lapsing. The leadership team knew the status quo was unsustainable. The question was whether to attempt a risky full rewrite or execute a careful, incremental migration. After evaluating options, they selected the incremental approach—guided by the principle that a working system is always better than a broken new one. ## Project Goals The transformation initiative was governed by four primary objectives, each tied to measurable business outcomes: 1. **Achieve 99.95% Uptime SLA:** The business could no longer tolerate unplanned downtime during peak shopping seasons. The target was single-digit seconds of planned maintenance per month with zero unplanned outages. 2. **Reduce Page Load Time to Under 2 Seconds:** Core Web Vitals had become a Google ranking factor, and user research showed that every second of load time cost approximately 7% in conversions. The goal was a 75% improvement in average page load time. 3. **Enable Daily Deployments:** The engineering team needed to ship features and fixes at the pace of the business. Moving from quarterly to daily deployments required decoupling the monolithic codebase and establishing robust CI/CD pipelines. 4. **Support 10x Traffic Growth:** With aggressive expansion plans for tier-2 and tier-3 cities, the platform needed to handle the equivalent of ten Big Billion Day events without performance degradation. Secondary goals included improving mobile conversion rates to at least 3%, reducing overselling incidents to under 0.1%, and achieving PCI-DSS Level 2 compliance. ## Our Approach The team adopted a pragmatic, business-driven migration strategy rather than a technical ideal. The guiding philosophy: migrate when you have a reason, not just because you can. **Strangler Fig Pattern:** Rather than attempting a big-bang rewrite, the team incrementally replaced monolith functionality with new services. New features were built as microservices from day one, while legacy functionality was slowly extracted behind well-defined APIs. This approach, inspired by Martin Fowler's Strangler Fig pattern, allowed the business to continue operating without a high-risk cutover. **Domain-Driven Design (DDD):** Before writing any new code, the team conducted a series of event storming workshops with business stakeholders to map out the core domains: Product Catalog, Shopping Cart, Order Management, Payment Processing, Inventory Management, Customer Accounts, and Analytics. These bounded contexts became the foundation for service boundaries. **Technology Selection Rationale:** - **Backend Services:** NestJS was chosen for new microservices due to its TypeScript foundation, decorator-based architecture, built-in dependency injection, and excellent support for microservice patterns including message brokers and event sourcing. The team already had strong JavaScript/TypeScript expertise, reducing the learning curve. - **API Gateway:** Kong was selected to route requests between the monolith and new services, handle authentication, rate limiting, and request transformation. This gateway allowed a gradual traffic shift without client-side changes. - **Frontend Web:** Next.js was chosen for the new storefront, enabling server-side rendering for SEO, static generation for product pages, and API routes for server-side logic. Incremental Static Regeneration (ISR) allowed the team to update thousands of product pages without full rebuilds. - **Mobile Application:** Flutter was selected for the mobile app rewrite, enabling a single codebase for Android and iOS while maintaining near-native performance. Hot reload accelerated development cycles, and the rich widget ecosystem matched the design team's vision for a premium mobile experience. - **Data Layer:** PostgreSQL was retained as the primary OLTP database, with Redis introduced for caching and session management. Elasticsearch replaced the legacy MySQL full-text search for product discovery. ClickHouse was evaluated for analytics workloads. - **Infrastructure:** AWS was chosen as the cloud provider, leveraging EC2 for compute, RDS for managed PostgreSQL, ElastiCache for Redis, S3 for static assets, CloudFront as a CDN, and ECS/EKS for container orchestration. **Phased Migration Plan:** The team divided the transformation into six phases over 18 months, each delivering business value before the next began: - Phase 1: Infrastructure modernization and CI/CD pipeline setup (Months 1-3) - Phase 2: Product catalog and search microservice (Months 4-6) - Phase 3: Shopping cart and checkout flow (Months 7-9) - Phase 4: Order management and fulfillment (Months 10-12) - Phase 5: Customer accounts, loyalty, and mobile app (Months 13-15) - Phase 6: Analytics, personalization, and full monolith decommissioning (Months 16-18) ## Implementation Details ### Phase 1: Infrastructure Foundation The first three months focused entirely on building the runway. The team set up AWS accounts with proper IAM roles, VPC segmentation, and monitoring infrastructure. Terraform managed infrastructure as code, ensuring reproducible deployments across staging and production environments. The CI/CD pipeline was built on GitHub Actions, with separate workflows for monolith deployments and new service deployments. Automated testing ran on every pull request—unit tests with Jest, integration tests with Supertest, and end-to-end tests with Playwright. Deployment to production required passing the full test suite, a security scan with Trivy, and peer code review. Observability was a priority from the start. The team deployed the ELK stack for centralized logging, Prometheus with Grafana for metrics, and OpenTelemetry for distributed tracing. Every microservice emitted structured JSON logs, and all services were instrumented with health check endpoints. ### Phase 2: Product Catalog and Search The product catalog service was the first to go live as a standalone microservice. Built with NestJS, it managed product information, categories, attributes, pricing, and media. The service exposed a GraphQL API using Apollo Server, allowing the frontend to request exactly the data it needed, reducing over-fetching. Product search migrated from MySQL full-text to Elasticsearch. The team built a real-time sync pipeline using Change Data Capture (CDC) from PostgreSQL's logical replication, feeding product changes into Elasticsearch via a NestJS event processor. This meant search results were updated within seconds of catalog changes, not hours. The new Next.js storefront used Incremental Static Regeneration to pre-render the 15,000 most-viewed product pages at build time, with ISR revalidating them every 60 seconds. Long-tail product pages were rendered server-side on demand. Edge caching on CloudFront was configured aggressively: product images and static pages cached at 200+ edge locations across India, with cache invalidation triggered by product updates. Average TTFB for cached pages dropped to under 100ms. ### Phase 3: Shopping Cart and Checkout The cart microservice handled anonymous and authenticated cart persistence, promotional code application, and pricing calculations. Built with NestJS and using Redis for high-speed cart access, the service reduced cart operations latency from 200ms to under 20ms. The checkout flow was rebuilt as a series of lightweight Next.js pages, each responsible for a single step: shipping address, delivery slot, payment method, and order review. The team introduced a progressive disclosure pattern that reduced form abandonment by 18%. The payment service abstracted multiple payment providers—Razorpay, PhonePe, and UPI—behind a unified interface. This abstraction allowed dynamic routing based on success rates, fees, and user preferences. Payment processing latency was reduced from an average of 1.2 seconds to 300ms. PCI compliance was achieved by moving all card data handling to tokenized flows with Razorpay. The application never touched raw card numbers, significantly reducing the compliance scope and security risk. ### Phase 4: Order Management and Fulfillment The order management microservice handled order creation, state transitions, cancellations, and returns. Built as an event-driven NestJS application using RabbitMQ as the message broker, the service ensured that all downstream systems—inventory, notification, analytics—were consistently updated. The fulfillment module integrated with third-party logistics providers through a standardized API, automatically selecting the optimal shipping partner based on destination pin code, package weight, delivery timeline, and cost. This reduced average delivery cost by 12% and improved on-time delivery from 78% to 94%. Real-time inventory tracking replaced the previous 15-minute batch updates. Using Redis as a write-through cache with PostgreSQL as the source of truth, inventory levels were updated atomically and visible across all channels within 30 seconds. ### Phase 5: Customer Accounts and Mobile Experience The Flutter mobile app was developed in parallel with the customer account microservice. The app shared API contracts with the web frontend, ensuring consistent data access patterns. Key features included: - Biometric authentication and social login - Real-time order tracking with push notifications - Personalized product recommendations using collaborative filtering - In-app customer support with live chat - Digital wallet and saved payment methods The team leveraged Flutter's widget library to create custom animations for page transitions and product carousels, achieving a mobile conversion rate of 3.4% within the first three months of launch. The loyalty program microservice introduced a tiered rewards system tied to purchase history, referrals, and engagement. Customers could earn and redeem points across web and mobile, with real-time balance updates. ### Phase 6: Analytics and Full Migration The final phase focused on decommissioning the legacy monolith. The team used feature flags to gradually shift traffic from the monolith to the new platform, starting at 5% and ramping to 100% over two weeks. Rollback procedures were tested and documented for every shift. A real-time analytics platform using ClickHouse collected events from all microservices, powering dashboards for business intelligence, fraud detection, and operational monitoring. The analytics team gained self-service querying capabilities through Metabase, reducing their dependency on the engineering team for data extraction. The monolith's MySQL database was retired after 60 days of stable operation on the new platform, with all data migrated and verified. ## Results The transformation delivered results across every dimension of the business. The following metrics demonstrate the impact: **Revenue Growth:** Monthly revenue grew from ₹2.1 crore to ₹9.2 crore within 12 months of completing the migration—a 338% increase. The improved conversion rates and mobile experience were the primary drivers. **Revenue per Visitor:** Average revenue per visitor increased from ₹28 to ₹95, an improvement of 239%. Better product discovery, personalized recommendations, and a frictionless checkout flow contributed to higher basket values. **Traffic Volume:** Monthly unique visitors grew from 180,000 to 750,000—a 317% increase—driven by improved SEO performance from Next.js SSR and faster page load times. **Search-to-Purchase Rate:** The new Elasticsearch-powered search with personalized ranking improved the search-to-purchase conversion from 2.1% to 4.8%, more than doubling the efficiency of organic traffic. **Operational Efficiency:** With daily deployments now standard, the engineering team shipped 147 features and bug fixes in the six months following migration completion, compared to just 7 features in the entire year prior. Developer satisfaction scores, measured through anonymous surveys, improved from 3.2 out of 5 to 4.6 out of 5. **System Reliability:** The platform achieved 99.97% uptime over the 12 months post-migration, with zero unplanned outages during major sales events. Mean Time to Recovery (MTTR) for incidents dropped from 4 hours to 12 minutes. **Mobile Growth:** Mobile now accounts for 72% of total traffic and 68% of revenue, up from 35% before the migration. The Flutter app has been downloaded over 400,000 times with a 4.5-star rating on both the App Store and Play Store. ## Metrics Summary | Metric | Before Migration | After Migration | Change | |--------|-----------------|-----------------|--------| | Avg Page Load Time | 8.2s | 1.7s | -79% | | Checkout Conversion Rate | 1.2% | 3.8% | +217% | | Monthly Revenue | ₹2.1 Cr | ₹9.2 Cr | +338% | | Monthly Unique Visitors | 180K | 750K | +317% | | Search-to-Purchase Rate | 2.1% | 4.8% | +129% | | Annual Deployments | 4 | 365 | +9000% | | Annual Uptime SLA | 99.1% | 99.97% | +0.87pp | | Incident MTTR | 4 hours | 12 minutes | -95% | | Mobile Conversion Rate | 0.8% | 3.4% | +325% | | Overselling Incidents/Month | 45 | 2 | -96% | | ## Key Lessons Learned The migration taught the ElectroMart team several lessons that will inform future technology decisions: **1. Incremental Beats Revolutionary:** The strangler fig pattern proved invaluable. By migrating piece by piece, the team could validate each service's performance and business impact before proceeding. There were moments of doubt, particularly during the cart migration, where legacy traffic was routed to both systems for comparison. But the incremental approach meant there was never a moment when the entire business was at risk. **2. Observability Is Not Optional:** Investing in logging, metrics, and distributed tracing from Day 1 paid dividends continuously. During the inventory migration incident in Month 10, where Redis hot keys caused a 30-minute performance degradation, the team identified the root cause and rolled back changes within 8 minutes—something that would have taken half a day with the old monitoring setup. **3. Domain-Driven Design Prevents Microservices Sprawl:** The event storming workshops forced the team to think about business boundaries before technical ones. Without this discipline, the team likely would have created a proliferation of microservices with unclear ownership, leading to the distributed monolith antipattern. **4. Frontend Performance Drives Revenue:** The correlation between page load time improvements and conversion rate increases was stronger than the team anticipated. Every 100ms improvement in page load time correlated with approximately 1.2% increase in conversion rate. Investing in CloudFront edge caching and Next.js ISR was not just a technical decision—it was a business decision. **5. Talent Investment Compounds:** The decision to upskill the existing team in TypeScript, NestJS, and cloud technologies rather than hire an entirely new team preserved institutional knowledge. The same engineers who understood the business deeply were the ones building the new platform, resulting in fewer misalignments between technical solutions and business needs. **6. Testing is a Feature:** The comprehensive automated testing strategy—including contract tests between services—prevented several potential production incidents. During the monolith decommissioning, the contract test suite caught 23 API incompatibilities that would have otherwise caused user-facing errors. ## Conclusion ElectroMart's transformation from a legacy monolith to a modern microservices-based platform demonstrates that technical excellence and business growth are not opposing forces—they are deeply interconnected. The 338% revenue growth would not have been possible without the architectural improvements, and the business case for the investment became self-evident as results materialized. The journey was not without challenges. There were late nights debugging Redis hot keys, tense production rollbacks during Diwali week, and moments when the team questioned whether the migration was worth the effort. But the discipline of incremental migration, the commitment to observability, and the alignment between technical and business goals turned a daunting challenge into a competitive advantage. Today, ElectroMart is not just surviving—it is thriving. The platform processes over 2 million monthly transactions, serves customers across 18 states with same-day delivery in major metros, and has become a trusted destination for electronics enthusiasts across India. The engineering team has grown from 3 to 18 developers, and the organization is now exploring AI-powered personalization and voice commerce to maintain its momentum. The most important lesson: a technology platform is never just a cost center. It is a strategic asset that can define whether a business leads its market or watches from behind. --- *This case study was prepared by the Webskyne editorial team based on extensive interviews with ElectroMart's leadership and engineering teams. All figures are based on publicly disclosed performance data verified through third-party analytics platforms.*