Creating a rating system as a part of the Bitpin company interview process.
- Requirements
- None Functional Requirements
- Entity Relationship Diagram
- System Architecture
- Endpoints Doc
- Rating Manipulation Prevention
- Load Balane
A system of users who can post content. The contents have a title and description. Users can rate content with a score from 0 to 5, but only once. Any repeated rating would be updated with the new score. Each content has several rates and average cumulative scores.
The system should detect and prevent rating manipulation. Because each content has millions of rates, calculating the average cumulative scores should be lazy and in real-time.
This is the data model of our entities in this system regarding the entities, relations, and attributes.
The following picture shows how different parts of the system interact.
-
PostgreSQL is used as the DB in this system.
-
Kafka is used to handle the thousands of requests for rating content.
-
Redis is used to retrieve popular content frequently and prevent rate cheating.
The /api/schema/swagger-ui/ URL provides complete API documentation. Parameters and possible outputs are described for each endpoint. One sample is below.
- User Signup
- Endpoint:
/api/user/signup/ - Parameters:
-
Example :
{ "username": "RandomUser", "password": "RandomPassword", "email": "random@gmail.com" }
-
- Response :
201-Created: User has been created400-Bad Request: Missing some parameters
- Endpoint:
To prevent any possible fraud in rating contents we used a weighted rating system in which all the rates do not have the same effect. Based on the number of rates a content had in the past hour a new rate would affect the average score differently. It has two main components:
- Redis Cache: to count how many rates have been submitted for specific content.
- A function to calculate new rate weight based on the number of previous rates.
- By using a Kafka queue in front of the API gateway we control the heavy load of rating different contents.
- There is an interface in which the logic of retrieving the list of contents can changed to use the Redis cache for frequent GET requests.

