System design scenario
Design a news feed (like Facebook or X)
Intermediate
A social feed under a daily traffic wave. Feeds are assembled from a timeline cache, with a slow ranking API on the critical path.
▶ Simulate this designThe goal
Keep p99 < 300 ms and error rate < 0.10% at 200,000 req/s for 5s.
- Peak load
- 200,000 requests per second
- Traffic mix
- 95% reads, 5% writes
- p99 latency
- under 300 ms
- Error rate
- under 0.10%
The starting architecture
The simulator opens with this design. It is deliberately too weak for the goal: run it and watch which component saturates first.
- CDN (CDN, 20 instances): Caches public assets and some anonymous feed responses at the edge.
- API gateway (Load Balancer, 2 instances): API gateway: auth, routing and rate limits for feed requests.
- Feed service (Service, 30 instances): Assembles a user feed from cached timelines and ranking scores.
- Timeline cache (Cache, 4 instances): Precomputed timelines keyed by user; misses fall back to the posts database.
- Posts DB (Database): Posts and social graph storage with read replicas.
- Ranking API (External API, 10 instances): Third-party style ranking service that scores feed items; slow and capacity-limited.
How to approach it
The hints unlock one at a time in the app. Try the design yourself before reading them.
Show the hints
- The daily wave only reaches the target near its peak: watch the run around t = 60s.
- The ranking API is slow and small. Raise its capacity or cut its timeout and add retries.
- Turn on autoscaling for the feed service, but remember instances take time to boot.
What the simulator shows you
SimLoad models every component as a queue with real capacity, latency, timeouts and retries, so you see utilisation, p50/p99 latency, errors and monthly cost change as you scale. Insights name the bottleneck in plain language, and the capacity planner sizes the fix. A reference solution that meets the goal is verified by automated tests.
▶ Try it in the simulator