## 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. ```hint Define what one rating means Aggregate correctness depends on whether an edit replaces a user's prior rating or creates another independent contribution. ``` ### 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. ```hint 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. ``` ### 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. ```hint Make moderation reversible A hidden review and its evidence can be appealed or restored; a silently deleted record cannot. ``` ### 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. ```hint 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. ``` ### What a Strong Answer Covers - Starts with review identity and lifecycle semantics. - Separates authoritative reviews from search, rating, and cache projections. - Includes trustworthy moderation, appeal, and privacy boundaries. - Makes consistency, hot-key, and reconciliation behavior explicit. ### Follow-up Questions 1. How would you prevent one business's rating summary from becoming a write bottleneck? 2. What should readers see while a reported review is awaiting moderation? 3. How would you rebuild ratings after discovering a projection bug? 4. Which signals would you use to rank reviews without silencing new reviewers?