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.