A paid email app was competing with free ones.
It needed reasons to stay, and a cheaper engine to run.

A single codebase now runs on macOS, Windows, iOS and Android. A feature is built once rather than four times, and a dependency change can only break in one place. On that base, the product work added:

• Read receipts let a sender know when an email has been opened.
• Reusable templates and snippets cut repeated emails down to one click.
• Expiring links let someone share an email, backed by S3 and RDS with a 30-day default expiry, so the recipient sees it with its formatting and attachments, without needing an account.
• Dark mode adapted on its own, following the time of day.

All workloads once sat on the same undifferentiated servers, so a sync storm could starve push notifications. Now:

• Containerized workloads run on EKS, with worker groups specialized for crawling, actions, notifications and API traffic.
• SQS and Gearman distribute asynchronous jobs, so background processing scales separately from interactive requests.
• DynamoDB holds message metadata and tracking state, S3 stores attachments and shared assets, and account and sharing data, which needs relational structure, sits in RDS, each store chosen for how its data gets used.
• Public load balancers front the API tier and internal ones spread work across the EC2 worker pool, so each layer scales on its own.

The team also put a SQLite-and-Thrift metadata cache on the device, SQLite behind a Thrift interface, holding 60 days of email metadata, or 15 during a trial, so the message list renders almost at once and the back end is shielded from the read fan-out an email client generates.

Crawling, notifications and the API each run on their own workers, so a busy job in one can't slow the others.

Autoscaling adjusts capacity across every tier, and commitment-based pricing (reserved instances and savings plans) covers the steady part of the demand, which a consumer email service has every hour of every day. Serverless logic takes on work that doesn't need always-on servers.

Workloads are spread across independent, federated units that each handle their own crawling, actions and notifications, which keeps a failure inside its own unit. CloudWatch alerting is scoped the same way, unit by unit, and that keeps a real signal from getting buried. AWS Systems Manager runbooks detect, contain and fix routine failures on their own. The on-call engineer is paged only for incidents that need judgment, and the separate worker groups tell them exactly where to start looking.