System requirements

Functional:

• It should show the view-count on a particular video

Non-Functional:

• Correctness, it should not include fraudalant views.
• It should be highly available as the call-volume is going to be high..
• We should be fine with eventual consistency here as it is not like the moment a new user watches the video, it shall show the counter during the same second. it could have some lag
• If a same user is reloading the same video again, it shall count that as a new count, unless the previous view was just less than 5 seconds ago.
• It needs to be of very low-latency.

Capacity estimation

• Assumptions:
  • The scope of the problem is to show the count only and not the user-ids list who has watched the video.
  • The authZ/authN has already been taken care of
• We can expect the TPS of the operation as, let say, there are 100M DAU and assuming each is viewing an unique video(in worst case), so, we would be having around 1150 TPS
• It could also be possible that a large number of active-users are viewing a particular trending video.
• the counter is always increasing.

API design

• GET: getLiveCount(video-id)
  • for the video-id, if exists, it shows the video count
  • Response: code- 200, response:
    • { "count" : <>}
• PUT: updateLiveCount(video-id, user-id, location)
  • For the video-id, if the user-id hasn't watched it in last 5 seconds, update the counter.
  • Response: code: 201.

Database design

• video-count
  • <video_id, hashed_id(location_coodinates_of_viewer), count>
    • video_id: represent the unique id of the video
    • hashed_id(location_coordinates_of_viewer): takes the hash of the location_coordinates(long, lat) with modulo(lets say 100). This is there to minimize the concurrent-updates(write call blocker) on a single video_id, hence we would be having at max. 100 records per video(trending ones). We could also leverage range-based hashing for the {lat, long}, hence keeping together the closer co-ordinates in a single record(this would cause some skewness, and hence write-blockers, when we have some trending video at a regional level only. So, going forward with hash-based approach seems better.
    • count: the count for that particular hashed(location_coord).
  • Since, this table looks pretty straightforward, we could go with key-value based database, this one guarantees single digit microsecond latency, with DDB, we have to get all the count-records for a particular video-id(at max. 100 records would be there) and then in-memory calculating the sum.
  • There is one more option, that we can go with sql and use a query like select sum(count) where video_id=<id> group by video_id, since we have only 100 records, it would be a bit faster only, else we could leverage hyper-log-log to approximately give us the live-count for a video with very less margin of error.

We will also have one redis kind of DB(recent-visitors) in place, which will have TTL of 5 seconds for each record, it is having data like

• • {<video_id>, <user_id>, <timestamp>}
  • It indicates that for the video_id, user_id had last-watched the video at time: <timestamp>
  • There will be only one record per <video_id>, <user_id>.. in this case, our <video_id> becomes the partition-key and <user_id> will become the sort-key.
  • We can just fire the call like select timestamp where video_id is "" and user_id is "" to figure out the last viewed timestamp.
• We will also have one flow for analytics purpose:
  • We can publish the view-event to a persistent store using some analytics service.
  • Then later on, we could write spark-jobs to normalize/filter out the data and form user-preferences, trends, recomendation service/ML models.

High-level design

• Video-analyser service: The service is to maintain the live-count for view, like, comment on a particular video. The service serves two operations
  • getLiveCount(video_id): It makes a call to the DB: video-count and get the total count
  • updateLiveCount(video_id, user_id, <coordinates_for_user>): First it fires call to the bloom-filter to figure out that user_id is already present in the system or not,
    • if not: it just updates the video-count and recent-visitors(this one with ttl of 5 seond)
    • if yes: it first checks the recent-visitor table for the record-existence:
      • if found, it updates the timestamp there and circuit breaks
      • if not found, it updates the video-count DB and updates the recent-visitor one(with 5 second ttl)
• We are also publishing the view-event to a persistent storage(in form of plain json with folders partitioned as timestamps), this would be further filtered out/refined using spark-jobs and would serve as input for recomendation/ML models.
• We could also leverage one cache withiin video-analyser service, with a small TTL of some seconds(let say 1 seconds). it should be fine to have lag of 1 second as it would, instead of getting the data from db everytime will leverage cache. The eviction policy would be least recently used.

Request flows

• Video-analyser service: The service is to maintain the live-count for view, like, comment on a particular video. The service serves two operations
  • getLiveCount(video_id): It makes a call to the DB: video-count and get the total count
  • updateLiveCount(video_id, user_id, <coordinates_for_user>): First it fires call to the bloom-filter to figure out that user_id is already present in the system or not,
    • if not: it just updates the video-count and recent-visitors(this one with ttl of 5 seond)
    • if yes: it first checks the recent-visitor table for the record-existence:
      • if found, it updates the timestamp there and circuit breaks
      • if not found, it updates the video-count DB and updates the recent-visitor one(with 5 second ttl)
• We are also publishing the view-event to a persistent storage(in form of plain json with folders partitioned as timestamps), this would be further filtered out/refined using spark-jobs and would serve as input for recomendation/ML models.
• We could also leverage one cache withiin video-analyser service, with a small TTL of some seconds(let say 1 seconds). it should be fine to have lag of 1 second as it would, instead of getting the data from db everytime will leverage cache. The eviction policy would be least recently used.

Detailed component design

High-level design

• Video-analyser service: The service is to maintain the live-count for view, like, comment on a particular video. The service serves two operations
  • getLiveCount(video_id): It makes a call to the DB: video-count and get the total count
  • updateLiveCount(video_id, user_id, <coordinates_for_user>): First it fires call to the bloom-filter to figure out that user_id is already present in the system or not,
    • if not: it just updates the video-count and recent-visitors(this one with ttl of 5 seond)
    • if yes: it first checks the recent-visitor table for the record-existence:
      • if found, it updates the timestamp there and circuit breaks
      • if not found, it updates the video-count DB and updates the recent-visitor one(with 5 second ttl)
• We are also publishing the view-event to a persistent storage(in form of plain json with folders partitioned as timestamps), this would be further filtered out/refined using spark-jobs and would serve as input for recomendation/ML models.
• We could also leverage one cache withiin video-analyser service, with a small TTL of some seconds(let say 1 seconds). it should be fine to have lag of 1 second as it would, instead of getting the data from db everytime will leverage cache. The eviction policy would be least recently used.

Trade offs/Tech choices

• We are not saving the unique-user IDs while maintaing the count, although this could be later figured out as we are emitting this to a ingestion service via kafka as well.
• We could have multiple replicas of the video-analyser-service to avoid the fault-tolerance.
• DDB implicitly provides the fault-tolerance by having multiple replicase saved across multiple partitions.

Failure scenarios/bottlenecks

• We will be leverage canaries which will continuously firing the calls and auto cut tickets/ alarms in case of any discrepancy. The service will also emit metrics which we can use laterwards to create alarms/dashboards.
• All our calls to DB, internal services will be with exponential backoff with jitter strategy..

Future improvements

• We will be leverage canaries which will continuously firing the calls and auto cut tickets/ alarms in case of any discrepancy. The service will also emit metrics which we can use laterwards to create alarms/dashboards.
• We could leverage hyper-log-log in future to quickly provide the probabilistic count once the application scales further..