Scaling Our AWS Infrastructure: Lessons from Meddy

Meddy, a four‑year‑old startup that grew from zero to three million users, faced increasing technical debt in its original monolithic AWS architecture, leading to deployment pain points, data‑persistence issues, and scaling bottlenecks.

The team first split the monolith by moving the PostgreSQL database to Amazon RDS, storing uploaded media in S3, and managing deployments with Elastic Beanstalk, which eliminated many manual steps that previously relied on git pull from GitHub.

Search functionality, originally built with PostgreSQL trigram similarity, was migrated to a dedicated Elasticsearch instance on EC2, with an index updated on every record change and a nightly cron job to rebuild the full index.

To remove the 10‑second downtime caused by Elastic Beanstalk’s single‑instance deployment, an Application Load Balancer was placed in front of an Auto Scaling group, enabling rolling deployments without service interruption.

Rendering was refactored from a Django + AngularJS hybrid to a pure client‑side approach; static assets were served from S3 via CloudFront, while Lambda@Edge and the prerender.io service handled bot detection and pre‑rendering to preserve SEO.

Shared caching and task scheduling problems were solved by moving Redis and Celery to separate services using ElastiCache and centralizing periodic tasks, avoiding duplicate executions across servers.

Short‑link redirection was implemented with two Lambda functions that read a DynamoDB table containing hash‑to‑URL mappings; an API Gateway exposed the redirect function, eliminating the need for a large redirect table.

For logging and monitoring, the team adopted Grafana Loki for log aggregation and Grafana (backed by AWS CloudWatch) for metrics visualization, providing a unified observability stack across all services.

The combined changes resulted in a more modular, resilient, and observable cloud infrastructure that supports Meddy’s continued growth.