Problem Statement: A Trust Fabric for Commerce
Frames reviews and ratings as a read-dominant trust product, not a comment table.
Problem statement
Design a reviews and ratings platform for a large e-commerce marketplace. Buyers submit star ratings, written reviews, and optional photos or videos. The system verifies whether a reviewer actually purchased the item, aggregates per-product rating summaries, ranks and filters reviews for display, detects fake or incentivized content, moderates policy violations, and serves all of it on product pages at catalog scale.
This is not a CRUD blog. It is a trust fabric. Shoppers make purchase decisions from aggregate stars and the top three reviews; sellers live and die by their rating distribution; and the moment fake reviews visibly distort either, the marketplace loses conversion and credibility. The product therefore has two separate jobs: a read-dominant distribution engine where averages, histograms, and review lists must load in milliseconds for hundreds of millions of page views, and a trust pipeline where every submission is validated, scored, moderated, and provenance-checked before it can influence a single aggregate.
Why the problem is distinctive
A product detail page renders in under 300 ms or the shopper bounces. The rating badge and first review page are on that critical path. Yet a review submission may take seconds to validate purchase, scan for spam, and moderate, and that is acceptable. The architecture must therefore split the world: reads are cached, replicated, and eventually consistent within a freshness budget; writes flow through a durable, auditable pipeline where correctness beats latency.
The second distinctive property is adversarial load. Reviews directly move revenue, so sellers buy positive reviews, competitors post negative ones, brigades coordinate voting, and bots flood new products. A design that treats submission as an ordinary authenticated write will be poisoned within weeks. Verified-purchase proof, fraud scoring, voting integrity, and moderation are architecture requirements, not features bolted on later.
The four architectural planes
- Ingestion plane: submission, validation, purchase verification, media upload, idempotency.
- Aggregation and distribution plane: rating counters, histograms, review indexes, caching, CDN, read APIs.
- Trust and moderation plane: fraud scoring, policy checks, human review, appeals, takedowns.
- Analytics and learning plane: rating-distribution analytics, model training, A/B evidence, seller insights.
A strong answer keeps these planes separate. Aggregation must survive a moderation backlog. Moderation must never depend on the read cache. Learning must not silently rewrite published aggregates.
Key Highlights
- •Reads dominate writes by roughly two orders of magnitude; the read path is the design driver.
- •Aggregates are denormalized, event-driven counters with explicit freshness budgets, not live SQL GROUP BY queries.
- •Every submission passes purchase verification and fraud scoring before it can move an aggregate.
- •Moderation is an asynchronous pipeline with a human fallback; it must not block safe reads.
- •The four planes are ingestion, aggregation/distribution, trust/moderation, and analytics/learning.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate the read-dominant distribution path from the correctness-dominant trust path before choosing any store."
- "Aggregates are derived state with a freshness budget; the review ledger is the durable source of truth."