Scaling from one user to millions

This walkthrough follows the primer's worked example of growing a service on AWS from one user to tens of millions. Each stage is driven by measuring the bottleneck, not by a user count: the primer gives no fixed thresholds, because they depend entirely on the workload.

Stage 1: A single box

Web server and database run on one machine, with DNS (such as Route 53) mapping the domain to its address. Scale by choosing a bigger box. Simple to run, but there is a hardware ceiling and no redundancy: one crash takes the whole service down.

Stage 2: Separate the database and static content

Move the database to its own managed instance (such as RDS) and static content to an object store (such as S3). Web and database tiers can now be sized and scaled independently.

Stage 3: Load balancer, redundancy and a CDN

Put a load balancer in front of several stateless web servers spread across availability zones; health checks stop routing to an instance that fails. Run the database as a primary with a standby for failover. Move static (and some dynamic) content to a content delivery network (CDN) such as CloudFront, closer to users.

Stage 4: Caching and read replicas

Web workloads are often read-heavy: the primer's example assumes 100 reads for every write. Add:

• An in-memory cache (such as ElastiCache running Redis or Memcached) for frequently read data, which cuts both database load and latency.
• Read replicas that copy the primary asynchronously and serve reads, leaving the primary for writes.

Stage 5: Autoscaling

Instead of sizing for the peak by hand, let the platform add and remove web and application servers as load changes.

Stage 6: Asynchronous work, NoSQL and a warehouse

Move slow work (sending email, processing images, payments) onto a queue (such as SQS): the application server enqueues a job and responds immediately, for example with HTTP 202 Accepted ("accepted for processing, but not yet completed"), and worker services process the queue. Move data that no longer fits the relational model to a NoSQL store, and older data used for analytics to a data warehouse.