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.
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.