System requirements

Functional:

• Count video views
• Updated in real-time

Non-Functional:

• Scalable (high volume traffic)
• Security (prevent fraudulent views)
• Performance (minimal latence for real-time updates)

Capacity estimation

• Daily active users between 10 and 100M
• 5 to 20 videos watched per user per day
• Max 2B views (100M * 20)

API design

PUT /videos/count/{video-id}

returns 200 when OK

GET /videos/stats/{video-id}

returns

{

video_id,

views_count,

last_view

}

Database design

Table WatchCount

• video_id INT
• count INT
• last_view DATETIME

High-level design

• Stats service is responsible for providing real-time updates to content creators
• Count service is called each time a video is watched
• Both services can scaled independently

Request flows

Detailed component design

• The count service immediately updates the counters in the cache
• The serialization to database is handled by a different service that pools data from the cache at a defined interval
• This way database serialization doesn't slowdown the counter service because we don't need to update it for every call to the count service

Trade offs/Tech choices

• A Redis cluster could be used for the counters cache

Failure scenarios/bottlenecks

• Having asynchronous serialization to database might expose to (minor) data loss in case of failure of the counter cache nodes but this is acceptable as this system isn't critical

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?