Bird
Raised Fist0
LLDsystem_design~25 mins

Rating and review system in LLD - System Design Exercise

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Rating and Review System
Design covers backend services, database schema, and API flow for rating and review management. Frontend UI and payment integration are out of scope.
Functional Requirements
FR1: Users can submit ratings and text reviews for products or services.
FR2: Each product or service can have multiple reviews from different users.
FR3: Users can update or delete their own reviews.
FR4: Display average rating and total number of reviews per product.
FR5: Support pagination and sorting of reviews (e.g., newest, highest rating).
FR6: Prevent users from submitting multiple reviews for the same product.
FR7: Allow moderation to flag or remove inappropriate reviews.
Non-Functional Requirements
NFR1: Handle up to 1 million products and 10 million users.
NFR2: Support 100,000 concurrent review submissions and reads.
NFR3: API response time p99 under 300ms for reading reviews.
NFR4: System availability of 99.9% uptime.
NFR5: Data consistency for user reviews and ratings.
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
❓ Question 6
Key Components
API Gateway or Load Balancer
Authentication and Authorization Service
Review Management Service
Database (Relational or NoSQL)
Cache Layer for frequently accessed data
Moderation Service
Message Queue for asynchronous tasks (e.g., notifications, moderation)
Search or Indexing Service for sorting and filtering
Design Patterns
CQRS (Command Query Responsibility Segregation) for separating read and write workloads
Eventual consistency for updating average ratings asynchronously
Rate limiting to prevent spam reviews
Soft delete for reviews to support moderation
Pagination and cursor-based navigation for review lists
Reference Architecture
          +---------------------+
          |   API Gateway / LB  |
          +----------+----------+
                     |
          +----------v----------+
          | Authentication Svc  |
          +----------+----------+
                     |
          +----------v----------+          +------------------+
          | Review Management   |<-------->| Moderation Svc   |
          | Service             |          +------------------+
          +----------+----------+
                     |
          +----------v----------+          +------------------+
          | Database (SQL)       |          | Message Queue    |
          +----------+----------+          +------------------+
                     |
          +----------v----------+
          | Cache (Redis/Memcached) |
          +---------------------+
                     |
          +----------v----------+
          | Search / Indexing   |
          +---------------------+
Components
API Gateway / Load Balancer
Nginx / AWS ALB
Route incoming requests and balance load across services
Authentication Service
OAuth 2.0 / JWT
Verify user identity and permissions
Review Management Service
RESTful API in Node.js / Python
Handle review creation, update, deletion, and retrieval
Database
PostgreSQL
Store reviews, ratings, users, and product data with strong consistency
Cache
Redis
Cache popular product reviews and average ratings for fast reads
Moderation Service
Microservice with admin UI
Flag, review, and remove inappropriate content
Message Queue
RabbitMQ / Kafka
Handle asynchronous tasks like notifications and updating aggregates
Search / Indexing Service
Elasticsearch
Support sorting, filtering, and full-text search on reviews
Request Flow
1. User sends request to submit or update a review via API Gateway.
2. Request is authenticated by Authentication Service.
3. Review Management Service validates and writes review data to the database.
4. Review data is published to Message Queue for asynchronous processing.
5. Cache is updated or invalidated for the affected product's reviews and average rating.
6. Moderation Service consumes flagged reviews from Message Queue for review.
7. User requests to read reviews are served from Cache or Search Service for fast response.
8. Search Service indexes reviews for sorting and filtering queries.
Database Schema
Entities: - User(user_id PK, username, email, ...) - Product(product_id PK, name, description, ...) - Review(review_id PK, user_id FK, product_id FK, rating INT, review_text TEXT, created_at TIMESTAMP, updated_at TIMESTAMP, is_deleted BOOLEAN, is_flagged BOOLEAN) Relationships: - User 1:N Review (one user can write many reviews) - Product 1:N Review (one product can have many reviews) Constraints: - Unique(user_id, product_id) to prevent multiple reviews by same user on one product - Index on product_id and created_at for sorting and pagination - Index on is_flagged for moderation queries
Scaling Discussion
Bottlenecks
Database write contention when many users submit reviews simultaneously.
Cache invalidation delays causing stale average ratings.
Search service indexing lag for new or updated reviews.
Moderation service overload with high volume of flagged content.
API Gateway becoming a single point of failure under heavy load.
Solutions
Use database sharding or partitioning by product_id to distribute write load.
Implement asynchronous batch updates for average ratings with eventual consistency.
Use near real-time indexing with incremental updates in the search service.
Scale moderation service horizontally and use automated filters to reduce manual load.
Deploy multiple API Gateway instances with health checks and auto-scaling.
Interview Tips
Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data model, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.
Clarify user roles and review lifecycle including moderation.
Explain choice of relational database for consistency and uniqueness constraints.
Discuss caching strategy to meet latency requirements.
Describe asynchronous processing for scalability and eventual consistency.
Highlight how to handle high read and write loads separately.
Mention security and abuse prevention like authentication and rate limiting.

Practice

(1/5)
1. What is the primary purpose of a rating and review system in an online store?
easy
A. To process payment transactions
B. To collect user feedback and calculate average product ratings
C. To manage product inventory levels
D. To store user passwords securely

Solution

  1. Step 1: Understand the system's goal

    A rating and review system is designed to gather user opinions and ratings about products.

  2. Step 2: Identify the main function

    It calculates average ratings to help other users make decisions quickly.

  3. Final Answer:

    To collect user feedback and calculate average product ratings -> Option B

  4. Quick Check:

    Rating system = Collect feedback + average rating [OK]
Hint: Focus on feedback and rating calculation [OK]
Common Mistakes:
  • Confusing rating system with payment or inventory systems
  • Thinking it manages user credentials
  • Assuming it handles shipping or delivery
2. Which data structure is best suited to store individual reviews for quick lookup by product ID?
easy
A. Hash map with product ID as key and list of reviews as value
B. Array of reviews without indexing
C. Linked list of all reviews
D. Stack of reviews

Solution

  1. Step 1: Consider lookup efficiency

    Quick lookup by product ID requires a data structure with fast key-based access.

  2. Step 2: Choose appropriate structure

    A hash map (dictionary) allows O(1) average time to find reviews by product ID.

  3. Final Answer:

    Hash map with product ID as key and list of reviews as value -> Option A

  4. Quick Check:

    Fast lookup = Hash map [OK]
Hint: Use hash maps for fast key-based lookup [OK]
Common Mistakes:
  • Using arrays without indexing causes slow searches
  • Linked lists have O(n) lookup time
  • Stacks do not support direct lookup by key
3. Given the following pseudocode for updating average rating after a new review:
current_avg = 4.0
num_reviews = 5
new_rating = 5
new_avg = (current_avg * num_reviews + new_rating) / (num_reviews + 1)

What is the value of new_avg?
medium
A. 4.17
B. 4.16
C. 4.0
D. 4.5

Solution

  1. Step 1: Calculate total rating sum before new review

    Total sum = current_avg * num_reviews = 4.0 * 5 = 20

  2. Step 2: Add new rating and compute new average

    New sum = 20 + 5 = 25
    New average = 25 / (5 + 1) = 25 / 6 ≈ 4.1667

  3. Final Answer:

    4.17 -> Option A

  4. Quick Check:

    Average update formula ≈ 4.17 [OK]
Hint: Multiply avg by count, add new, divide by count+1 [OK]
Common Mistakes:
  • Forgetting to add new rating to total sum
  • Dividing by old count instead of count+1
  • Rounding too early causing wrong average
4. A rating system stores average rating and count per product. After deleting a review, the average becomes incorrect. What is the likely cause?
medium
A. Recalculating average using sum of all reviews
B. Using integer division instead of float division
C. Not updating the count of reviews after deletion
D. Storing reviews in a hash map

Solution

  1. Step 1: Understand average calculation

    Average = sum of ratings / count of reviews. Both must be accurate.

  2. Step 2: Identify deletion impact

    If count is not decreased after deleting a review, average calculation divides by wrong count.

  3. Final Answer:

    Not updating the count of reviews after deletion -> Option C

  4. Quick Check:

    Count mismatch causes wrong average [OK]
Hint: Always update count when reviews change [OK]
Common Mistakes:
  • Ignoring count update after deletion
  • Assuming recalculation always fixes average
  • Confusing data structure choice with calculation error
5. You want to design a scalable rating and review system for millions of products and users. Which approach best balances fast average rating queries and frequent review updates?
hard
A. Store all reviews and compute average on each query
B. Use a single database table without indexes
C. Cache only the latest review per product
D. Maintain precomputed average and count, update incrementally on review changes

Solution

  1. Step 1: Consider query and update load

    Millions of products and users mean many queries and updates.

  2. Step 2: Choose efficient strategy

    Precomputing average and count and updating them incrementally avoids scanning all reviews each time.

  3. Step 3: Evaluate other options

    Computing average on each query is slow; no indexes cause slow lookups; caching only latest review misses full rating info.

  4. Final Answer:

    Maintain precomputed average and count, update incrementally on review changes -> Option D

  5. Quick Check:

    Precompute + incremental update = scalable [OK]
Hint: Precompute averages, update on changes for scale [OK]
Common Mistakes:
  • Recomputing averages on every query
  • Ignoring indexing and caching strategies
  • Caching incomplete data causing stale info