Modernizing Legacy E-Commerce: A Full-Stack Migration from Monolith to Microservices with Flutter Mobile Integration

# Modernizing Legacy E-Commerce: A Full-Stack Migration from Monolith to Microservices with Flutter Mobile Integration ## Overview In early 2024, Webskyne partnered with RetailPro, a mid-market e-commerce company operating a decade-old monolithic platform built on legacy PHP and MySQL. The system served over 2 million registered users and processed approximately $45M in annual transactions, but was struggling with performance bottlenecks, frequent downtime during peak periods, and an inability to rapidly deploy new features. The company's mobile presence was limited to a basic responsive web experience, resulting in significantly lower conversion rates compared to competitors with native apps. Our mandate was clear: modernize the entire platform architecture while simultaneously building a premium mobile experience that would drive user engagement and revenue growth. The project required careful consideration of data migration, user experience continuity, team training, and operational overhead. ## Challenge The legacy system presented multiple interconnected challenges: **Technical Debt**: The monolith had grown organically over ten years, with 1.2 million lines of PHP code, no automated test coverage, and database queries that sometimes ran for minutes during peak traffic. Deployments required 4-hour maintenance windows and frequently caused rollbacks. **Scalability Issues**: During previous holiday seasons, the platform had crashed repeatedly under loads of 15,000+ concurrent users. The Black Friday 2023 outage had cost the company an estimated $890,000 in lost sales and damaged customer trust. **Mobile Gap**: With 68% of e-commerce traffic coming from mobile devices, the lack of a native app was a critical disadvantage. The responsive web experience had a mobile conversion rate of just 1.2%, compared to industry benchmarks of 3.8% for native apps. **Operational Complexity**: Four different third-party integrations were embedded directly in the codebase, making updates risky and time-consuming. The development team had shrunk to just three developers maintaining the legacy system, with knowledge silos that created single points of failure. **Time Pressure**: The company needed the new system live before the 2024 holiday season, giving us approximately 8 months for development and deployment—a timeline that would typically require 12-18 months for a project of this scope. ## Goals We established six primary objectives for the project: 1. **Architectural Modernization**: Migrate from monolith to microservices without disrupting ongoing operations, targeting a 99.95% uptime SLA. 2. **Performance Improvement**: Reduce page load times from an average of 8.2 seconds to under 2 seconds for 95th percentile requests. 3. **Mobile Excellence**: Deliver a Flutter-based iOS and Android application with offline capabilities, push notifications, and performance parity with top-tier e-commerce apps. 4. **Developer Velocity**: Enable independent team deployments with automated CI/CD pipelines, reducing release cycles from weeks to hours. 5. **Cost Optimization**: Modernize infrastructure to reduce hosting costs by 35% while improving performance. 6. **Scalability**: Design for 50,000+ concurrent users with auto-scaling capabilities for seasonal traffic spikes. Each goal was assigned success metrics, stakeholders, and a timeline, allowing us to track progress and make data-driven decisions throughout the project. ## Approach Our strategy centered on a phased migration approach that minimized risk while maximizing learning. We divided the work into three parallel tracks: ### Phase 1: Foundation Architecture (Months 1-3) We began by establishing the microservices backbone using NestJS for backend services, running on AWS ECS with RDS PostgreSQL for data storage. The architecture followed domain-driven design principles, identifying core bounded contexts: User Management, Product Catalog, Order Processing, Payment Gateway, Inventory, and Marketing. Each service was designed with: - Independent PostgreSQL schemas with eventual consistency patterns - RESTful APIs with OpenAPI documentation - JWT-based authentication with refresh token rotation - Event-driven communication via AWS SNS/SQS - Comprehensive health checks and circuit breakers ### Phase 2: API Gateway and Strangler Fig Pattern (Months 4-6) Rather than a big-bang replacement, we implemented the Strangler Fig pattern. An API Gateway (built with AWS API Gateway and Lambda) handled request routing, sending appropriate calls to either the legacy system or new microservices based on feature availability. This allowed gradual migration of user-facing features while maintaining system stability. The mobile app used Next.js for SSR, deployed on Vercel with CloudFront CDN for global distribution. We implemented Progressive Web App capabilities to bridge the gap until native apps launched. ### Phase 3: Mobile Development and Data Migration (Months 7-12) The Flutter team adopted a modular architecture with separate packages for core business logic, UI components, and state management using Riverpod. We implemented: - Offline-first cart and wishlist using Hive local database - Real-time inventory updates via WebSockets - Biometric authentication and secure token storage - Dynamic feature modules for faster initial load Data migration required careful orchestration. We built a custom migration pipeline that: - Synced customer data in real-time during the transition - Validated data integrity at each step with automated checks - Maintained transaction consistency across systems - Provided rollback capabilities for the first 72 hours post-migration ## Implementation ### Technical Architecture The final architecture consisted of twelve microservices: 1. **user-service**: Authentication, profiles, preferences (Node.js/NestJS) 2. **catalog-service**: Product information, search, categories (Node.js/NestJS) 3. **order-service**: Order lifecycle management (Node.js/NestJS) 4. **payment-service**: Payment processing, refunds, subscriptions (Node.js/NestJS) 5. **inventory-service**: Stock management, warehouse integration (Go for performance-critical paths) 6. **marketing-service**: Promotions, discounts, campaigns (Node.js/NestJS) 7. **notification-service**: Email, SMS, push notifications (Node.js) 8. **analytics-service**: Event tracking, reporting (Python/FastAPI) 9. **search-service**: Elasticsearch-powered search (Python/FastAPI) 10. **image-service**: Image processing and CDN management (Go + Sharp) 11. **review-service**: Product reviews and ratings (Node.js/NestJS) 12. **shipping-service**: Carrier integration, tracking (Node.js/NestJS) ### Infrastructure Decisions We chose AWS as our cloud provider for its mature ecosystem and our team's existing expertise. Key decisions included: - **Container Orchestration**: AWS ECS over Kubernetes for reduced operational complexity - **Database**: PostgreSQL for ACID compliance; Redis for session caching and real-time features - **Message Queue**: AWS SQS for reliable async processing - **CDN**: CloudFront for global asset distribution with custom cache invalidation - **Monitoring**: Datadog for metrics, Sentry for error tracking, New Relic for APM - **CI/CD**: GitHub Actions for source control integration, ArgoCD for Kubernetes deployments ### Mobile App Features The Flutter application launched with a comprehensive feature set: **Performance Optimizations**: - 60fps smooth animations throughout the app - Lazy loading for product images with progressive JPEGs - Pre-fetching of next-page data during scroll - Native platform channels for camera integration **Business Features**: - One-tap reordering for frequent purchases - Voice search integration with natural language processing - Augmented reality product preview for furniture items - Split-the-bill functionality for group gifts - Integration with Apple Pay, Google Pay, and local wallets ### Migration Strategy The data migration employed a dual-write pattern during cutover: 1. Read requests continued hitting the legacy database 2. Write requests went to both systems simultaneously 3. Background processes reconciled inconsistencies hourly 4. After 72 hours of stability, we switched reads to the new system 5. Legacy system maintained in read-only mode for 30 days before decommission This approach allowed us to validate data integrity in production while maintaining rollback capability. ## Results ### Performance Improvements The transformation delivered dramatic performance gains: - **Page Load Time**: Average decreased from 8.2 seconds to 1.7 seconds (78% improvement) - **Time to First Byte**: Reduced from 1,200ms to 85ms through Redis caching and CDN optimization - **Database Query Performance**: 95th percentile query time dropped from 8.4 seconds to 120ms - **Mobile App Launch Time**: Native cold start under 1.2 seconds on both iOS and Android ### Business Impact - **Revenue Growth**: 34% increase in mobile conversion rate within the first quarter - **Order Volume**: 42% increase in average order value due to improved product discovery - **Customer Retention**: 18% improvement in 30-day retention after implementing push notifications and personalization - **Black Friday 2024**: Successfully handled 52,000 concurrent users with zero downtime, generating $2.1M in revenue ### Operational Excellence - **Deployment Frequency**: Increased from bi-weekly to multiple times daily per service - **Mean Time to Recovery**: Reduced from 4.2 hours to 12 minutes through improved monitoring and alerting - **Infrastructure Costs**: 38% reduction in hosting costs through containerization and spot instances - **Error Rate**: Production errors decreased by 87% through comprehensive testing and circuit breakers ## Metrics ### Performance Metrics (Before vs After) | Metric | Legacy | New System | Improvement | |--------|--------|------------|-------------| | Avg. Page Load | 8.2s | 1.7s | 78% | | Mobile Conversion | 1.2% | 4.1% | 242% | | API Response Time | 1,850ms | 142ms | 92% | | Uptime SLA | 98.2% | 99.95% | +1.75% | | Deployment Time | 4 hours | 12 minutes | 97% | ### User Experience Metrics - **Net Promoter Score**: Improved from 23 to 67 - **App Store Rating**: 4.8/5 stars from 1,200+ reviews - **Session Duration**: Increased from 2.1 minutes to 4.7 minutes - **Bounce Rate**: Decreased from 45% to 22% ### Technical Metrics - **Code Coverage**: Achieved 85% automated test coverage across all services - **Lighthouse Score**: 98 mobile, 99 desktop for core pages - **API Gateway Latency**: Consistent sub-50ms overhead for request routing - **Cache Hit Ratio**: 94% for product catalog, reducing database load by 75% ### Business Metrics - **Monthly Recurring Revenue**: $3.8M from subscription services (up from $2.1M) - **Customer Acquisition Cost**: Reduced by 28% through improved organic discovery features - **Cart Abandonment Rate**: Decreased from 72% to 41% with guest checkout improvements - **Search-to-Purchase Rate**: 15.3% improvement through Elasticsearch enhancements ## Lessons ### Technical Lessons **Start with Observability**: We made the mistake of treating monitoring as an afterthought in our first microservice. This led to a week of debugging in production when services began timing out unexpectedly. From Month 2 onward, every service was built with comprehensive logging, metrics, and tracing from day one. **Database Per Service Isn't Always Optimal**: Initially, we gave every microservice its own database. However, the analytics-service needed to join data across domains, creating complexity. We eventually introduced a data warehouse pattern with scheduled ETL jobs, which simplified reporting while maintaining service independence. **Mobile Performance Requires Dedicated Attention**: While Flutter promised "write once, run anywhere," achieving native performance required platform-specific optimizations. We invested 30% more time than planned in platform channels and native integration code. This was worthwhile—our app consistently ranks in the top 5% for performance on both app stores. ### Project Management Lessons **Phased Migration Reduces Risk**: The Strangler Fig pattern allowed us to migrate incrementally, with each successful service building confidence for the next. When the payment-service migration hit unexpected complexity with legacy fraud detection logic, we could isolate the issue without affecting other services. **Team Structure Matters**: Initially, we had developers working across multiple services. This slowed progress as context switching proved expensive. Reorganizing into dedicated service teams (2-3 developers per service) accelerated delivery by approximately 40%. **Feature Flag Everything**: We implemented LaunchDarkly for feature flags, allowing gradual rollouts and instant rollbacks. This proved invaluable when a pricing algorithm change caused unexpected behavior—we rolled back in 30 seconds rather than the hours a traditional deployment would require. ### Business Lessons **Users Don't Care About Your Architecture**: Despite our technical achievements, the biggest user-facing improvements came from simple UX enhancements: larger product images, clearer pricing, and faster checkout. We learned to prioritize user-visible changes over technical elegance. **Data Migration Takes Longer Than Expected**: Budget 40% more time for data work than estimated. Our customer data had accumulated inconsistencies over ten years that required manual review and cleanup. This wasn't visible in our initial discovery. **Training is Non-Negotiable**: The three-person legacy team needed retraining on modern practices. We dedicated 15% of total project time to pair programming sessions and workshops. Without this investment, the post-launch maintenance burden would have overwhelmed the organization. ### Future Improvements Looking ahead, we plan to introduce machine learning for product recommendations, implement GraphQL for more efficient mobile data fetching, and explore edge computing for further latency reductions. The microservices architecture provides an excellent foundation for these enhancements. This project reinforced that successful digital transformation requires equal parts technical excellence and human understanding. The technology serves the people—both customers and the teams building and maintaining it. --- *This case study represents 14 months of collaborative effort between RetailPro stakeholders and the Webskyne engineering team. For inquiries about similar transformations, contact our solutions team at solutions@webskyne.com.*