Problems / Real world, hard
The news feed as first built: no feed cache in front of the timeline store, and the feed API, ranking model, social graph and fan-out workers at an eighth of their real size. 5,000 requests a second arrive: 85% feed loads that are ranked on every load, 15% new posts fanned out to followers. Most feed loads fail.
Unlock it once for 25 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.
Grow it into the real architecture: every goal must hold at 5,000 requests a second. You may add components, connect them and resize anything.
Like a coding problem, a solution has to pass every case, not just the one it was built for. Submit in the lab runs all 6; 2 of them are hidden until then.
5,000 requests a second for 20 seconds: 85% feed (reads), 15% post (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 |
|---|---|---|
| DDoS protectionDDoS protection | Traffic enters here.Calls API gateway.Volumetric floods are absorbed at the network edge, spread over many locations, before they reach you. | 100000 slots |
| API gatewayAPI gateway | DDoS protection forwards to it.Calls Feed API, Post API.Gateways centralise auth, rate limits and routing so each service does not reimplement them. | 50000 slots · 1,200,000 calls/min |
| Feed APIApp service | API gateway forwards to it for /feed.Calls Timeline store (Cassandra), Feed ranking model, Social graph (TAO).Little's law: throughput ≈ concurrency ÷ latency. 200 slots at 50 ms serve about 4,000 req/s. | 1 replicas × 100 slots · timeout 1.0 s |
| Timeline store (Cassandra)Key-value store | Feed API calls it for reads. Fan-out workers calls it.Key-value stores spread keys over partitions; one very popular key can overload a single partition. | 16 partitions × 2,000 ops/s |
| Feed ranking modelRanking model | Feed API calls it.Feeds rank a few hundred candidates per load with a learned model; retrieval narrows millions of posts first. | 256 slots |
| Social graph (TAO)Graph database | Feed API calls it on 30% of requests.Graph databases follow relationships directly, so multi-hop queries avoid large joins. | 64 slots |
| Post APIApp service | API gateway forwards to it for /post.Calls Posts (MySQL, sharded), Post events (Kafka) (publishes).Little's law: throughput ≈ concurrency ÷ latency. 200 slots at 50 ms serve about 4,000 req/s. | 1 replicas × 100 slots · timeout 1.0 s |
| Posts (MySQL, sharded)SQL database | Post API calls it.Postgres runs one process per connection, which is why poolers like PgBouncer sit in front of busy databases. | 4 vCPU · 50 connections |
| Post events (Kafka)Event stream | Post API publishes to it.Calls Fan-out workers.Kafka keeps order only within a partition, so the partition key decides what stays in sequence. | 8 partitions · retention 600 s |
| Fan-out workersWorker | Post events (Kafka) consumes from it.Calls Timeline store (Cassandra).Queues deliver at least once, so a worker can see the same message twice. | 32 concurrent jobs |