...
The Flink jobs are used to read and compute the summary of a collection consumption progress when the user view ends. It also computes the score for the current view and best score using all the previously previous views.
| Info |
|---|
|
Once the view ends, the progress can and score will be updated either synchronously or asynchronously
Progress Update: Sync
...
Pros:
There will no lag between viewer read and viewer summary.
No need of a separate sync process
Cons:
Updating multiple cassandra tables might have impact on performance with huge load
Progress Update: Async
...
Pros:
Can expect better performance as we update only
user_content_consumption
Cons:
Expect a lag between viewer read and viewer summary responses.
Need a separate sync process on failure of the progress updates.
Handling View Service different consumption and tracking Use-cases:
Use Case - #1 - When the user tries to consume or track the content outside batch - will be storing the higher hierarchy with content id while consuming
Use Case - #2 - When the user tries to consume the content/course within batch/program - will be storing the higher hierarchy with respective fields
Use Case - #3- When the user tries to track his/her or batch/program status - will be capturing the entire status from aggregated table - user_activity_agg for status
...
Note: Currently batch-id field will be holding the context id data internally asynchronously by the flink jobs.
...
Viewer-Service - Content Consumption Scenarios:
The user can consume a content by searching it in our platform (organically) or via a collection when the user enrolled to a course.
With Viewer-Service, we will support tracking individual content consumption also. Below details explain how the data will be stored for a content consumption in different scenarios.
...
User | Accessing Content | Table - user_content_consumption |
|---|---|---|
A |
<By enrolling to Collection> |
|
A |
<By using platform search> |
|
Content View Lifecycle:
When the user view the content in context of a collection and batch, for the first time its start, progress update and end triggers are processed. Revisit (2nd - nth view) of the content will be ignored to process and update the DB.
...
If, collectionId and batchId are part of the request, then, individual content progress and overall collection progress is captured and computed.
...
In case of only userId and contentId, the progress is captured only for that content
...