Introduction
This wiki explain the current design and implementation problems to handling the of tracking and monitoring service data collections. The challenges we have at scale and the proposed approach design to handle itthem.
Background & Problem Statement
Design
Viewing Service:
Viewing Service collects the “content view updates” and generate events to process and provide summary to the users.
When a user starts viewing a content, a view entry created. There are three stages when a user view the content. They are start, progress and end. Considering these three stages we have 3 API endpoints to capture this information for each stage.
An event will be generated when a content view ends. The summary computation jobs will read these event to process and compute the overall summary of the collection.
The computed summary will be available from API interface to download and view.
Summary Computation Jobs - Flink:
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 previous views.
| Info |
|---|
|
Once the view ends, the progress and score will be updated 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
...
class-1-maths (Collection)
single-digit-addition (Content)
<By enrolling to Collection>
...
userId: A
collectionId: class-1-maths
batchId: class-1-maths
contentId: single-digit-addition
The sunbird platform supports collection tracking and monitoring. It uses the below APIs to capture the content tracking data, generates progress and score metrics and provide the summary.
Content State Update API - To capture content progress and submit assessment.
Content State Read API - To read the individual content consumption and assessment attempts status.
Enrolment List API - To access all the enrolment metrics of a given user.
The content state update API capture the content progress and assessment data. It generate events for score and overall progress computation by activity-aggregator and assessment-aggregator jobs.
We have a single API (Content State Update) to capture all the tracking information. So, it has a complex logic to identify the given input is for content progress or assessment submission and etc,.
...
Key Design Problems:
Single API to capture all the tracking data.
Read after write of consumption data and basic summary.
Design
Viewing Service:
Viewing Service collects the “content view updates” and generate events to process and provide summary to the users.
When a user starts viewing a content, a view entry created. There are three stages when a user view the content. They are start, progress and end. Considering these three stages we have 3 API endpoints to capture this information for each stage.
An event will be generated when a content view ends. The summary computation jobs will read these event to process and compute the overall summary of the collection.
The computed summary will be available from API interface to download and view.
Summary Computation Jobs - Flink:
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 previous views.
| Info |
|---|
|
Once the view ends, the progress and score will be updated 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.
...
| Info |
|---|
|
...
Handling collection and batch dependencies:
For view start, end and update, courseId and batchId are non-mandatory. This would enable to track the progress for any content which is not part of a course.
This is handled in two ways:
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
...
V1 vs V2 APIs:
We will create a version column for course_batch table and update the default value (1) for all the existing rows.
...
New batches creation will set the version as 2.
...
If the batch version is 2, it uses v2 API endpoints from viewing-service.
...
enable to track the progress for any content which is not part of a course.
This is handled in two ways:
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
...
V1 vs V2 APIs:
We need to continue supporting the current APIs(v1) before deprecate and delete. So, it requires to work with both the APIs with backward compatibility.
Enhance V1 APIs to read summary from aggregate table.
Enhance the below APIs to read the progress and score metrics from user_activity_agg table.
Enrolment List API.
Content State Read API.
One time Data migration:
The content status and score metrics data should be updated to user_activity_agg table from user_enrolemnts and assessment_agg table for all the existing enrolment records.
API Spec
Content View Start
| Expand | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
Request:
Response:
|
...
| Expand | ||
|---|---|---|
| ||
Response:
|
Conclusion:
<TODO>