Katkat
Back

Design a Food Review Platform

DoorDashSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a food review platform for discovery, ratings, review text, optional dish-level content, and trusted aggregates. Define entity and review contracts, search and read paths, moderation, abuse resistance, privacy, scaling, and operational recovery.

Design a Food Review Platform

Design a platform where users discover food businesses, read reviews, and submit ratings and review text. Clarify whether reviews apply to restaurants, individual dishes, or both, and whether ordering or delivery is outside the system.

Part 1 — Define the Product and Data Contract

Specify users, businesses, dishes if needed, reviews, ratings, photos, moderation state, and the read and write APIs. Define whether one user may review an entity more than once and how edits affect aggregates.

What This Part Should Cover

  • Stable entity and review identities.
  • Rating scale, review lifecycle, and duplicate-review policy.
  • Idempotent creation and versioned edits.
  • Authorization and visibility rules for authors, owners, moderators, and readers.

Part 2 — Serve Discovery and Review Reads

Design business or dish lookup, nearby or text search if required, review pagination, sorting, rating summaries, photos, caching, and consistency after a new review.

What This Part Should Cover

  • Primary records plus derived search and aggregate views.
  • Stable cursor pagination with a deterministic tie-breaker.
  • Rating count and sum updates that handle edits and removals.
  • Explicit freshness for search, summaries, and detail pages.

Part 3 — Moderate Abuse and Preserve Trust

Handle spam, harassment, fake reviews, business-owner disputes, reports, automated signals, human review, appeals, and privacy.

What This Part Should Cover

  • Moderation states separate from destructive deletion.
  • Rate, account, and relationship signals without claiming they prove fraud alone.
  • Reviewer evidence, appeal history, and auditable decisions.
  • Protection of personal data and sensitive location information.

Part 4 — Scale and Operate the System

Discuss partitioning, hot businesses, write and read amplification, search-index lag, media delivery, retries, reconciliation, and metrics.

What This Part Should Cover

  • Partitioning that avoids one global review lock.
  • Idempotent change events and repairable projections.
  • CDN-backed media with safe upload processing.
  • Metrics for freshness, aggregate drift, abuse, and user-visible latency.

Hints

Hint 1

Define what one rating means: Aggregate correctness depends on whether an edit replaces a user's prior rating or creates another independent contribution.

Hint 2

Keep the ledger behind the average: Store the accepted reviews so a displayed average can be recomputed rather than relying only on one mutable number.

Hint 3

Make moderation reversible: A hidden review and its evidence can be appealed or restored; a silently deleted record cannot.

Hint 4

Expect popular entities to be hot: A launch or viral review can concentrate reads and writes on one business even when the overall key distribution looks balanced.

Follow-up questions

  • How would you prevent one business's rating summary from becoming a write bottleneck?
  • What should readers see while a reported review is awaiting moderation?
  • How would you rebuild ratings after discovering a projection bug?
  • Which signals would you use to rank reviews without silencing new reviewers?