Problems / Real world, hard
A story goes viral: traffic ramps to 4×. The CDN has 256 MB of edge storage for half a million pages, and the origin API renders pages at 6 ms of CPU each on 2 vCPUs per replica.
Free to open. Runs in your browser, no sign-up.
Success ≥ 99%, p99 ≤ 500 ms.
1,000 requests a second, ramping to 4× for 30 seconds: 98% reads, 2% writes.
What each component does in this design, and what calls it. The simulator mimics each one from these settings.
| Component | Its job here | Settings |
|---|---|---|
| CDNCDN | Traffic enters here.Calls Load balancer.A CDN keeps copies at edge locations near users, so a cache hit skips the trip to your origin. | – |
| Load balancerLoad balancer | CDN forwards to it.Calls API.Layer 4 balancers route by IP and port; layer 7 balancers read HTTP and can route by path or header. | – |
| APIApp service | Load balancer forwards to it.Calls Redis cache (checked first), Postgres.Little's law: throughput ≈ concurrency ÷ latency. 200 slots at 50 ms serve about 4,000 req/s. | 2 replicas × 150 slots · timeout 1.0 s |
| Redis cacheCache | API checks it first for reads.An in-memory cache like Redis usually answers in well under a millisecond inside one region. | 90% hit rate |
| PostgresSQL database | API reads it when Redis cache misses. API calls it for writes.Postgres runs one process per connection, which is why poolers like PgBouncer sit in front of busy databases. | 8 vCPU · 60 connections |
Try it first. Open one hint at a time if you get stuck.
Check the CDN hit rate: most pages are fetched from the origin.
Then check the origin’s CPU, not its slots.
Edge storage first (cheapest capacity), then replicas for the origin.
Give the CDN more edge storage, then scale the API for what still reaches the origin.