Loading...
We can lookup the videoId from the cache service and retrieve the view count.
The requestContext can be investigated to determine if the calling client is on a list of blocked users to determine a fraudulent view.
If valid, we can lookup the videoId from the cache service and increment the view count. The view count should be persisted to the DB and the cache should be updated.
incrementViewCount would first ensure the view is valid, i.e use the requestContext to determine if the requesting agent is on a blocked list of users. If yes, do not increment the view count.
getViewCount could request the view count from the Redis cache.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
The API service could retrieve and update the view count in the database directly, however the db reads and writes are likely to be slow. Instead, we could submit the job to a queue (i.e. SQS) to be picked up by a worker thread who can be responsible for the update. A queue system has the ability to scale its workers faster than scaling up more web servers. The worker thread can then be responsible for updating the cache. Multiple worker threads may want to update the counter for the same videoId simultaneously. This could result in a race condition when reading/writing the counter value. To avoid this, we would want to ensure using atomic operations available in Redis.
See Trade offs/Tech choices
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?