Design Top-K System — Section 2: Scaling & Non-Functional Requirements
Topic: Design a Top-K system (songs, ads, videos, posts)
Audience: Senior / Staff / Principal software engineers
Goal of this section: Quantify scale, traffic, storage, and define concrete NFRs.
1. Traffic & Scale Assumptions
We design for an internet-scale consumer product (YouTube / Spotify / TikTok class).
1.1 Read Traffic (Top-K Queries)
| Surface | QPS (Peak) | Notes |
|---|---|---|
| Home feed | 150K | Cached but still heavy |
| Trending page | 40K | Global + regional |
| Search assist | 20K | Category-based |
| Ads serving | 200K | Very latency sensitive |
Total Peak Read QPS: ~400K–500K
Read pattern:
- Extremely skewed (global + top regions are hot)
- Same Top-K list requested repeatedly
1.2 Write Traffic (Events)
Assume 1B DAU-scale platform.
| Event Type | Events / user / day | Total / day | Peak EPS |
|---|---|---|---|
| Impressions | 100 | 100B | ~2M |
| Clicks / Plays | 10 | 10B | ~200K |
| Likes / Shares | 2 | 2B | ~40K |
Total peak ingestion: ~2.2M events/sec
Key properties:
- Write-heavy
- Append-only
- Late and duplicated events possible
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson