Requirements

Functional Requirements:

• Count views for each video accurately, ensuring every legitimate view is counted, even under high traffic.
• Display real-time or near-real-time view counts to users and content creators.
• Prevent fraudulent or bot views using techniques like watch duration thresholds, rate limiting, IP analysis, CAPTCHA, or device fingerprinting.
• Provide content creators with view count trends broken down by time period (daily, weekly, monthly) for analytics and insights.

Non-Functional Requirements:

• High availability — if the view count system goes down, YouTube looks broken
• Scalability — needs to handle millions of views per second during viral videos
• Low latency — view count should update and display near instantly
• Accuracy — every legitimate view must be counted, none lost
• Fault tolerance — if one server crashes mid-count, no views should be lost
• Eventual consistency — view count doesn't need to be perfectly exact every millisecond, being slightly behind is acceptable

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...

The api involved in this are:

POST which sends a view count to the system

GET which retrieves the most recent view count number and gives it back to the client

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.

The high level starts at the client which watches a video and sees the view count. This information is sent to the api gateway which distributes the task with a load balancer which sends out that this user has seen the video with a POST api call. then because there are so many of these tasks we use a queue and use asynchronous processing to do this in the background so we are not slowing down the user's experience. We want to prioritize high avalibility, not consistency. Once the queue is setup, the request hits the worker server, which finds the database current number and updates it. Finally we have 2 databases one primary and one secondary in case it goes down which has the updated view count number.

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.

The reason we have a kafka queue is so that we do not hold up the user experience for our user. We do not want there to be downtime just because there are a lot of requests to be processed by the user. This way we can keep the application running and show them a false maybe not exact up to date number for now. We do this asynchronously.

The point of the load balancer is that it distributes the information among multiple servers, so one server is not having too much load. We can use a least connections algorithm to find the server with the least amount of load.