Requirements

Functional Requirements:

1. Count views — every legitimate view of a video gets counted (accurately, none lost)
   1. If a legitimate views a video more than once
2. Display counts — viewers and creators see near-real-time numbers
   1. We need to know if someone is a viewer or a creator
3. Filter fraud — bot/fake views must not be counted (watch-time thresholds, rate limiting, IP/device analysis)

Non-Functional Requirements:

Throughput: Assume YouTube-scale (we always design for millions of users). Let's do the math:

• ~1 billion views/day
• Average: 1B / 86,400 sec ≈ 12K views/sec
• Peak (viral spikes): 5–10× → 50K–100K+ views/sec at peak
• Reads (displaying counts) far outnumber writes — roughly 10:1 or higher, so peak reads can hit ~1M/sec
• the ingestion pipeline must absorb 100K writes/sec, and caching handles the read-heavy side.

What counts as a view - they clicked on the video or they watched until the end?

Capacity Estimation

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

POST v1/views/{view_id} --> Write that a viewer viewed a video - takes in a user id, video id

PUT v1/views/{view_id} --> updates the existing view, how long of the video did they watch

GET v1/views/ --> takes in a user id, based on whether they are creator or viewer, it returns the correct counts for views. a creator will see more details than a viewer.

GET v1/views/analytics --> return a summary of views

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

client(YouTube UI) --> view-service --> filter-fraud-service --> display-service

view-service receives the views - it ties the views to a user, it determines if it is a creator/viewer,

Database Design

.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

fraud detection service will read the views from the database, and it will process them based on whether they are fraud. It can do some level of aggregation (like if a IP viewed the same video 1M times in 1 min, it is likely a bot, it can check user from the same IP, ...etc).

analytics service will hit the database and it will aggregate statistics hourly or daily to have it rolled up, if the user wants to know last 30 days of traffic, average length of video watched...etc. it will store the aggregate statistics in new tables in the database, then can be hit first before the un-aggregated (raw) db tables.

the ingestion service receives all the views, and it is the first layer in the system. it writes to the db in the raw db tables. it ensures consistency. it makes sure a view is not counted twice. it validates consistency by checking viewer, video id, if it is already been counted in the last 5 seconds. it allows for tracking views from the same viewer in different time periods ( a user can view the video 10 min ago, a user can restart the video, a user can view the video last year or last month). it receives the view event. a view event will contain (user id, video id, starting point in video in second (did a user start video at 0s or 120 sec...etc).