Design a Review and Rating System

Pre-Computed Aggregates and Event Pipeline

Every product page view depends on sub-50 ms star ratings, which makes live SQL COUNT queries across billions of rows impractical. Review writes persist to PostgreSQL and fan out asynchronously through Kafka, maintaining a five-minute eventual consistency window for public star displays. For caching strategies, review Caching Patterns & Invalidation.

Event Bus Design (Kafka)

Topic: review-created
  Partitions: 64
  Partition key: product_id (preserves per-product aggregate ordering)
  Retention: 7 days
  Replication factor: 3, min.insync.replicas: 2

Producer: Review Service after PostgreSQL INSERT (idempotent producer)
  Event: { review_id, product_id, user_id, stars, body, media_urls[], timestamp }

Consumer groups:
  1. aggregate-worker: INCR product_ratings star_N, recompute avg, and update Redis rating:{product_id} with TTL 300s
  2. search-indexer: full-text index review body in Elasticsearch
  3. fraud-detector: ML and NLP spam and bot scoring, then flag for moderation
  4. notification: alert seller of new reviews
  5. ai-summary: weekly batch LLM summary per product (staff tier)

Topic: review-vote-events: async INCR helpful_count (avoids hot row contention on viral reviews)

Sync path: POST review -> INSERT PostgreSQL -> publish event -> return 201 Created
Async path: aggregate update in under 5s; reads hit Redis cache (99% hit rate)
DLQ: review-created-dlq; nightly batch recomputes aggregates from reviews table

Bayesian Average Rating Calculation

A single five-star review should not outrank a product with ten thousand positive reviews averaging 4.5 stars. Bayesian averaging pulls sparse rating distributions toward a global prior mean to prevent sample-size distortion.

Product A: 1 review, 5.0 avg. Product B: 10K reviews, 4.5 avg.
Simple average ranks A higher. That's statistically wrong.

Bayesian Average (what Amazon and IMDb use in production):
  bayesian_avg = (C * m + sum_of_ratings) / (C + total_reviews)
  
  C = 25 (minimum reviews required for confidence)
  m = 3.7 (global platform average rating)
  
  Product A: (25 * 3.7 + 5) / (25 + 1) = 3.75
  Product B: (25 * 3.7 + 45000) / (25 + 10000) = 4.498
  
  Product B correctly ranks higher. As review volume increases,
  the Bayesian average smoothly converges to the true sample average.

Multi-Signal ML Fraud Detection

Abuse mitigation combines behavioral telemetry, order verification, text semantics, and graph network analysis to assign review confidence scores before public indexing.

Signals for ML fraud detection:

Behavioral:
  - Account age < 7 days and review posted: suspicious
  - 50 reviews in 1 day: automated bot behavior
  - All 5-star or all 1-star patterns: biased review history
  - Copy-pasted text across unrelated products

Purchase verification:
  - No purchase record: unverified review receiving lower aggregate weight
  - Purchased and returned same day: suspicious behavior

Text analysis (NLP):
  - Generic text: "Great product! Highly recommended!" without specific product attributes
  - Sentiment mismatch: enthusiastic text paired with a 1-star rating
  - Language similarity across reviews submitted from the same IP address

Network analysis:
  - Multiple reviews from the same IP or device identifier for the same product
  - Review rings: coordinated clusters of accounts mutually reviewing identical products
  
Timing:
  - Product suddenly receives 500 5-star reviews in 1 hour compared to baseline 5 per day

ML Model (XGBoost):
  Features: all behavioral, textual, network, and timing signals
  Output: P(fake) probability score
  
  P(fake) > 0.8: auto-suppress review and enqueue for human moderation
  P(fake) between 0.5 and 0.8: flag review with reduced weighting in aggregates
  P(fake) < 0.5: show normally
  
  Suppressed reviews are excluded from aggregate star distributions.
  Nightly batch reconciliation corrects totals for retroactively suppressed reviews.