Closed hsb1007 closed 7 months ago
Would like to take this up next!
/bounty $50
As discussed I am assigning it to you @rajdip-b !
💎 $50 bounty created by eronka
🙋 If you start working on this, comment /attempt #41
along with your implementation plan
👉 To claim this bounty, submit a pull request that includes the text /claim #41
somewhere in its body
📝 Before proceeding, please make sure you can receive payouts in your country
💵 Payment arrives in your account 2-5 days after the bounty is rewarded
💯 You keep 100% of the bounty award
🙏 Thank you for contributing to eronka/culero!
👉 Add a bounty • Share on socials
Attempt | Started (GMT+0) | Solution |
---|---|---|
🟢 @rajdip-b | Mar 21, 2024, 9:31:02 AM | #63 |
Can I be assigned? @hsb1007
/attempt #41
Algora profile | Completed bounties | Tech | Active attempts | Options |
---|---|---|---|---|
@rajdip-b | 5 eronka bounties + 11 bounties from 6 projects |
TypeScript, JavaScript, Jupyter Notebook & more |
Cancel attempt |
💡 @rajdip-b submitted a pull request that claims the bounty. You can visit your bounty board to reward.
After #34 we will need to have a caching mechanism as each user may get alot of reviews to process.
Considering that we have a caching layer set (using nest cache or anything else), we can follow this approach:
We maintain a key witht the user id. The relation will be userId -> score Whenever the review data is updated/added, we first write the data in the db, then we compute the score, then we add it in cache asynchronously. Whenever we try retrieving the data, we can check the cache for userId, see if the key is present. If yes, return it. If no, compute the score, store the cache, return the data. P.S. for better performance, we can use pg-boss to schedule jobs to run on postgres since we are already using psql.