System requirements

Functional:

1. Increment the view count if user views any video.
2. Content creators can view the count of video watched by users.

Non-Functional:

1. Scalable - System should scale during high traffic.
2. Highly Available - System should be available all the time.
3. Security - System should handle only the valid users are able to view and any DDOS attacks should be restricted.
4. Consistency - it should be eventual consistency.

Capacity estimation

DAU = 10M

if a users view video 2 times a day then total number :

WPS = 10M *2/24*60*60 = 200

API design

1 ) Add Video view count

POST /api/v1/count

parameter : user_id: String,UserName:String,video_id = UUID,count = integer

response: 200 OK

2) view Video view count

GET /api/v1/view/{creater_id}

/api/v1/view/{video_id}

Response : video_id,count

Database design

ContentCount Table:

video_id : UUID

count :Integer

creater_id

High-level design

Request flows

1) For the content viewed we need to increase the counter and for that we can get the request oncer user views the content and then pass that request to Kafka .We can spawn multiple worker nodes which can pull the request from Kafka cluster and then update the count in Database .

2)when the content creator or users want to view the content count then the request goes to view count service and fetches the content view count from Metallized views.

Detailed component design

1 .in the microservice we are storing the view count and for that when users view the content the request is published to Kafka so that worker can asynchronously increase the viewed content count into DB and based on number of videos Kafka can be portioned.

2)For the second microservices results are already calculated and keep into materlized views for fast view count and we can also use local cache to store the content count faster and use some TTL to invalidate the local cache,

Trade offs/Tech choices

1)As we are using ASynch process to create the video view count it may be delay in the video/content count increase ,so user may be see old data for some time.

2) For initial version we are using RDBM to store the video view count for simplicity

Failure scenarios/bottlenecks

1) We need to have WAF and rate limiter in place to prevent fraudulent update.

2) Also will use JWT for authorization who is trying to view the video count.

Future improvements

1. We can use kafka streams to real time view count of content.
2. Cassandra can be use to store the video count instead of RDBMS.