Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• Users should be able to see live view count/run-time changes
• ViewCount should not be incremented because of bots refreshing the page

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• System should be highly scalable(High read/write throughput)
• System should be highly available
• System should be realistically reliable(not payment system level accuracy expected)
• System should be eventually consistent
• Millions of users watching videos daily
• DAU : 10 M users
• Average length of content watched = 2 hours
• attention span = 30s to 2 min and they will watch the complete video if they like it
• so total no of videos watched by 1 person = 50
• So 500 M daily count
• we will later scale it to multi continent, but for now we can assume multiple cities across the country.(so still a multi region)

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

update count: POST count (accepts positive integer only)

view count: GET count

1. Update Count API (POST /count)
   • Description: This API will accept a positive integer to increment the view count for a specific video.
   • Endpoint: /count
   • Method: POST
   • Request Body:
   • { "videoId": "string", // The ID of the video being watched "increment": 1 // Positive integer value to increment}
   • Response:
   • { "success": true, "newCount": integer // The updated view count after increment}
   • Considerations: Implementing checks to ensure that the same user/view isn't counted multiple times (to mitigate bots), and ensure that increments happen atomically.
2. View Count API (GET /count/{videoId})
   • Description: This API retrieves the current view count of a specified video.
   • Endpoint: /count/{videoId}
   • Method: GET
   • Response:
   • { "videoId": "string", "currentCount": integer // The current view count}

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.

• clients hit server to update count
• Event stream for not losing data
• Even stream is separately and asynchronously read and processed by another server and it updates DB by processing one chunk at a time
• For reading the count value, we will read it from cache if its absent there we will read it from DB.
• Eventual consistency is fine here.

For DB we will use simple key value store, as its good for high write and read throughput. Consistency is not a big dealbreaker here.

This architecture is designed for high scalability and allows you to maintain eventual consistency, as specified in your requirements.

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.

How we will scale this:

• Kafka or event stream can easily handle quarter million requests per second per node; so its not a bottleneck for our design
• we can divide processing servers based on read and write traffic
• We can divide event stream, processing server and DB based on video id hash; so that all the load will not come on single node and we don't have to lock row at all; only one node will access one type of row and that way sharding will take care of contingency of resources and avoid concurrent writes.