Grokking the System Design Interview, Volume II
Vote
0% completed
YouTube Likes Counter: Capacity Estimation
On This Page
Step 3: Back-of-the-Envelope Estimation
Traffic Estimates
Storage Estimates
Step 3: Back-of-the-Envelope Estimation
Before defining the architecture, we must estimate the system scale to determine the necessary storage and throughput capacity.
Traffic Estimates
-
User Base: ~2 billion Monthly Active Users (MAU). We assume approximately 200 million Daily Active Users (DAU).
-
Write Throughput (Reactions):
- Daily Volume: Assuming 20% of DAUs react, at an average of 5 reactions (likes/dislikes) each, we expect ~200 million write events per day.
- Write QPS:
- Average: 200M / 86,400 seconds = about 2,300 QPS.
- Peak: Traffic is rarely uniform. Assuming a 5x peak during viral events or prime time, we must handle ~11,500 write QPS, with potential bursts up to 20k+ QPS.
-
Read Throughput (View Counts):
- Video Views: Assuming ~1 billion video views per day, the system fetches the video like count ~11,500 times per second.
- Comment Views: If an average view fetches counts for the top 20 comments, this adds 11,500 x 20 = about 230,000 read QPS.
- User State: The client must also check "Did I like this?" for every view.
- Total Read QPS: The system must sustain ~250,000+ read QPS. The extremely high Read-to-Write ratio (~100:1) dictates a heavy reliance on caching.
Storage Estimates
-
Count Storage (Aggregates):
- We store the total likes/dislikes per item. With hundreds of millions of videos and comments, this requires hundreds of millions of counter records. However, since each record is small (ID + Integers), the total dataset for active counts is manageable (in the gigabytes range) and fits easily in memory (Redis/Memcached).
-
Reaction Storage (User-Entity Relationship):
- To enforce "one like per user" and enable "unliking," we must store every specific user-to-video interaction.
- Volume: 200 million new likes/day translates to ~6 billion new records per month. Over 5 years, this grows to hundreds of billions of records.
- Size: If each record is about 64 bytes (IDs, timestamp, status), 6 billion records is about 384 GB of new data per month. Over five years that is roughly 23 TB. This requires a scalable, sharded database solution (e.g., Cassandra, DynamoDB, or sharded SQL).
Next: Step 4, where the API is specified.
On This Page
Step 3: Back-of-the-Envelope Estimation
Traffic Estimates
Storage Estimates