Grokking the System Design Interview, Volume II
Vote

0% completed

YouTube Likes Counter: Capacity Estimation

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.

Capacity estimation
Capacity estimation

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