You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation as of upto v1 , we update the scores by iterating through all the users.
Suppose we prune a challenge, what it does is iterate through the db removing the points of that challenge.
What if instead of storing the points in the DB, we instead store pointers to the scores of solved challenges? And then for getting score of a user, we iterate through challenges and calculate the score. What issue can this method resolve?
Consider the case of dynamic scoring. We continuously need to update the scores of the users. If we implement this, we reduce the load of the case when many users solve a particular challenge which creates a lot of threads, couple that with many users trying to fetch something from db. We are trading off this worst case with more load on every route which reduces the load that can result in downtime of the platform. We would be better off with little more load each time as compared to a lot of load a single time. This is based on the belief that number of users will be generally way more than number of challenges.
We, as of present, have only ideated on this. More research and feasibility test is required.
The text was updated successfully, but these errors were encountered:
The current implementation as of upto
v1
, we update the scores by iterating through all the users.Suppose we prune a challenge, what it does is iterate through the db removing the points of that challenge.
What if instead of storing the points in the DB, we instead store pointers to the scores of solved challenges? And then for getting score of a user, we iterate through challenges and calculate the score.
What issue can this method resolve?
Consider the case of dynamic scoring. We continuously need to update the scores of the users. If we implement this, we reduce the load of the case when many users solve a particular challenge which creates a lot of threads, couple that with many users trying to fetch something from db. We are trading off this worst case with more load on every route which reduces the load that can result in downtime of the platform. We would be better off with little more load each time as compared to a lot of load a single time. This is based on the belief that number of users will be generally way more than number of challenges.
We, as of present, have only ideated on this. More research and feasibility test is required.
The text was updated successfully, but these errors were encountered: