Design a Review and Rating System

Design a trustworthy product review and rating service with eligible writes, fast aggregate reads, moderation, and auditable corrections.

Design a trustworthy product review and rating service with eligible writes, fast aggregate reads, moderation, and auditable corrections. Use this guide to structure the discussion, test the design under pressure, and practise explaining trade-offs clearly.

Problem and Scope

Design the review and rating system for a large marketplace. Verified customers can rate a purchased product, optionally write a review, and later edit or delete it. Product pages must show the aggregate score, rating distribution, and review lists under several sort orders. Moderation may hide or remove content, and every state change must update customer-visible aggregates correctly. Define the APIs, data model, read and write paths, consistency boundaries, scaling strategy, and failure recovery.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

Customers can submit one rating and optional written review for an eligible purchase.
Customers can edit or delete their own review while retaining an auditable history.
Product pages show an aggregate rating, rating distribution, and paginated reviews.
The system supports moderation state and removes rejected reviews from customer-facing aggregates.

Non-functional requirements:

Review reads and aggregate ratings remain highly available under uneven product popularity.
A submitted review becomes visible within seconds without corrupting aggregate counts.
Authorization, purchase eligibility, and moderation decisions are enforced consistently.
The design tolerates retries and duplicate delivery without double-counting ratings.

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

Support hundreds of millions of products, tens of millions of daily review reads, and hundreds of thousands of daily writes.
A small number of popular products receive extremely bursty traffic and dominate read volume.
Review text and moderation metadata are retained for years, while aggregate ratings must be inexpensive to read.

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

Review, rating, eligibility, and moderation data model
Write path with idempotency and aggregate maintenance
Read path for product summaries, distributions, sorting, and pagination
Consistency choices between individual reviews and aggregate ratings
Hot-product partitioning, caching, and fan-out control
Moderation workflow, auditability, privacy, and operational recovery

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

How do you prevent retries from adding the same rating twice?
- Focus: Test idempotency keys, uniqueness constraints, and aggregate correction strategy.
How would you update the average rating when a customer edits a one-star review to five stars?
- Focus: Test incremental aggregation, source-of-truth ownership, and repairability.
A viral product receives a sudden burst of millions of reads. What becomes hot and how do you protect it?
- Focus: Test caching, partitioning, precomputed summaries, and degradation behavior.
How should removing a review after moderation affect public aggregates and audit history?
- Focus: Test state transitions, consistency, reversible changes, and moderation traceability.
How do users sort by recent, helpful, and highest-rated reviews without unbounded indexes?
- Focus: Test access-pattern-driven indexing, ranking, and pagination trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

Requirements and scope (15%): Clarifies and prioritizes the required behavior for Customers can submit one rating and optional written review for an eligible purchase; Customers can edit or delete their own review while retaining an auditable history; Product pages show an aggregate rating, rating distribution, and paginated reviews. Establishes the constraints that materially affect Design a Review and Rating System, including Review reads and aggregate ratings remain highly available under uneven product popularity; A submitted review becomes visible within seconds without corrupting aggregate counts. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Review, rating, eligibility, and moderation data model; Write path with idempotency and aggregate maintenance; Read path for product summaries, distributions, sorting, and pagination; Consistency choices between individual reviews and aggregate ratings. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
Data and scaling (25%): Uses workload assumptions such as Support hundreds of millions of products, tens of millions of daily review reads, and hundreds of thousands of daily writes; A small number of popular products receive extremely bursty traffic and dominate read volume to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Review, rating, eligibility, and moderation data model; Hot-product partitioning, caching, and fan-out control. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Write path with idempotency and aggregate maintenance; Consistency choices between individual reviews and aggregate ratings; Moderation workflow, auditability, privacy, and operational recovery. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Consistency choices between individual reviews and aggregate ratings; Hot-product partitioning, caching, and fan-out control; Moderation workflow, auditability, privacy, and operational recovery. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.