This case study is based on reporting originally published by crn.in and reflects the state of Medlife’s AWS infrastructure as of mid-2019. All quotes are attributed to Pranesh Vittal, database architect at Medlife.
Background: Healthcare at Scale in India
India’s healthcare system is vast, geographically dispersed, and unevenly distributed between rural and urban areas. Patients routinely visit multiple providers to complete a single care episode, and supply-chain logistics for medicines are correspondingly complex.
Medlife launched in 2014 as an online pharmacy and integrated healthcare platform. Its services include doctor consultations via outbound calls and diagnostic lab services from its Bangalore center. By 2019, Medlife operated in roughly 3,000 cities across India and ran 40 proprietary fulfillment centers. The company was cloud-native from day one, choosing Amazon Web Services (AWS) as its primary infrastructure provider.
Secure SMS Delivery with Amazon SNS
SMS is the dominant customer communication channel in India, where mobile-subscriber penetration significantly exceeds email adoption. Medlife sends customers up to three SMS updates per order — covering order receipt, dispatch, and estimated delivery time — making reliable message delivery directly tied to revenue.
After concerns arose about data handled by third-party SMS vendors, Medlife migrated to Amazon Simple Notification Service (Amazon SNS). The decision was driven by two factors:
- Security posture: AWS holds certifications including ISO 27001 and ISO 9001, which gave Medlife confidence in data handling for a regulated healthcare context.
- Delivery performance: The previous SMS provider suffered from dropped messages, causing lost orders. After moving to Amazon SNS, the SMS delivery SLA improved from 92% to 97%, with continued improvement expected.
Medlife now monitors messaging throughput and anomalies using Amazon CloudWatch, which provides alerting on unusual usage patterns — an important control for a service that processes high volumes of transactional SMS daily.
“We didn’t want to compromise data security. Hence, we went ahead with Amazon SNS due to the additional security that it had to offer, and the delivery timespans were quite fast.”
— Pranesh Vittal, Database Architect, Medlife
From Monolith to Microservices with Amazon ECS
Medlife’s engineering team made an early architectural decision to adopt a DevOps culture, and over time evolved from a monolithic (“meta”) architecture to a microservices model. They use Amazon Elastic Container Service (Amazon ECS) to orchestrate and manage their containers.
Key outcomes from this transition include:
- Growth from 5 to 40 microservices over two years, covering orders, procurement, and inventory management.
- Release cadence increased from two deployments per week to two deployments per day — a 7× improvement.
- Faster iteration from prototype to production, enabled by decoupling application components into independently deployable services.
Medlife was an early adopter of ECS in the AWS Mumbai region after the region launched in December 2017, having previously run ECS workloads out of Singapore. According to Vittal, ECS simplified container setup and deployment pipelines significantly for the team.
“Amazon ECS works like a charm for setting up our containers and deployments.”
— Pranesh Vittal, Database Architect, Medlife
Automation and Autoscaling for Rapid Growth
A high degree of infrastructure automation allowed Medlife to manage its production environment with a small engineering team — a significant cost advantage for a growing startup. AWS autoscaling proved particularly valuable during traffic surges, which are common in e-commerce and online pharmacy during promotional campaigns.
Medlife reported 10× growth between its second and third years of operation. AWS autoscaling enabled the platform to absorb that growth without requiring proportional increases in operations headcount or manual infrastructure management.
“The autoscaling works miraculously well, especially during surges. We just have to concentrate on our business growth and let AWS manage the infrastructure.”
— Pranesh Vittal, Database Architect, Medlife
Machine Learning: Stock Prediction and Batch Analytics
Medlife runs several machine-learning workloads on AWS to support pharmacy operations. The most demanding is a proprietary stock prediction tool that matches incoming orders to available inventory and requires sub-second response latency to function correctly at scale.
To support ML operations alongside batch processing, inventory prediction, and broader analytics, Medlife deployed Amazon Elastic MapReduce (Amazon EMR) clusters. EMR enables the team to run large-scale data processing jobs without managing the underlying Hadoop or Spark infrastructure directly.
Caching with Amazon ElastiCache for Redis
Medlife uses MongoDB as its primary database, deployed on Amazon EC2 instances. During high-traffic marketing campaigns, database performance degraded under load. To address this, the team evaluated Amazon ElastiCache for Redis as a caching layer during a proof of concept.
The results were strong enough that ElastiCache for Redis was promoted to production, where it now serves static and semi-static data from cache, reducing read pressure on the primary MongoDB cluster and maintaining acceptable response times during traffic spikes.
AWS Premium Support and Cost Optimization
Medlife subscribed to the AWS Premium Support tier to gain access to AWS solutions architects for pre-implementation reviews and debugging assistance. This support was particularly useful during the ECS proof of concept, where AWS engineers helped resolve integration issues quickly.
The team uses AWS Trusted Advisor to identify cost-reduction opportunities across their infrastructure, consistent with a broader emphasis on cloud financial management. Vittal noted that the recommendations from AWS solutions architects have had a measurable impact on cost optimization outcomes.
“AWS puts a lot of emphasis on security and cost optimization and offers the right solutions for the right problems while keeping costs in mind.”
— Pranesh Vittal, Database Architect, Medlife
What’s Next: Data Lake, Voice, and Computer Vision
As of mid-2019, Medlife’s engineering roadmap included:
- Data lake implementation to consolidate customer data and support deeper analytics across business verticals.
- Computer vision for product image and video validation — likely to support prescription verification and product authentication workflows.
- Voice interfaces and chatbots for customer care automation.
These initiatives reflect a broader pattern in healthcare technology: applying ML and AI capabilities to reduce manual effort in high-volume, compliance-sensitive workflows.
Key AWS Services Used by Medlife
| AWS Service | Use Case |
|---|---|
| Amazon SNS | Transactional SMS notifications to customers |
| Amazon CloudWatch | Monitoring SMS delivery and detecting usage anomalies |
| Amazon ECS | Container orchestration for 40+ microservices |
| Amazon EC2 | Hosting primary MongoDB database |
| Amazon ElastiCache (Redis) | Caching layer to reduce database load during traffic spikes |
| Amazon EMR | ML workloads, batch processing, and analytics |
| AWS Trusted Advisor | Cost optimization and security recommendations |
| AWS Premium Support | Pre-implementation reviews and debugging assistance |
Takeaways for DevOps Engineers
- SNS for transactional messaging is a viable alternative to third-party SMS aggregators when data security and delivery reliability are non-negotiable requirements.
- Migrating from monolith to microservices iteratively — starting with high-churn domains like orders and inventory — can dramatically increase deployment frequency without a full rewrite.
- Caching with Redis via ElastiCache is a well-proven pattern for protecting relational or document databases during marketing-driven traffic spikes.
- EMR for ML batch workloads removes cluster management overhead and integrates naturally with other AWS analytics services.
- Engaging solutions architects before large migrations, rather than after problems occur, reduces rework and helps teams get architecture decisions right on the first attempt.