Design an Online Course Marketplace Review System Schema
DoorDashSoftware Engineer · OnsiteLast updated
Design the review and rating feature of an online course marketplace where only learners who completed a course may rate it, with the discussion centered on table design, keys, constraints, and the indexes each read path needs.
Design the review feature for an online course marketplace. Once a learner wraps up a course, they're allowed to post a star rating plus a written review, and shoppers browsing the catalog lean on those reviews to pick what to take next.
Touch the whole system, but plan to spend most of your time on the data model: what each table holds, how rows relate and reference one another, what rules the database itself enforces, and how the day-to-day reads and writes actually hit that model. Throughput and infrastructure sizing are yours to assume reasonably — the bulk of the interviewer's questions will stay on the model itself.
Constraints and Clarifications
- Traffic volume, response-time targets, and any per-feature limits aren't handed to you — name the numbers and rules you're choosing to assume.
- Assume the platform already has tables for learners, instructors, courses, course modules, and enrollments; the review feature builds on top of these.
Clarifying Questions
- Is a review for the course as a whole, for individual modules within it, or both?
- Must a learner have an enrollment marked complete to review, or is any enrollment enough? Can a learner review a course more than once if they retake it?
- Once posted, can a learner go back and change or remove a review — and if a dispute or moderation review comes up later, does an older version need to still be recoverable?
- Do reviews support photos or attached code samples? Is there a moderation step before a review becomes visible?
- What's shown to a browsing learner: a rolled-up score and tally for the course, a feed ordered by freshness, a feed ordered by peer-voted helpfulness? Does the instructor get a public reply?
- How quickly after a review is submitted must it be reflected in the course's displayed average rating?
Part 1 — Entities, keys, and constraints
Design the core tables: what a review row contains, how it's tied to the enrollment that earned the right to write it, and what constraints prevent duplicate, orphaned, or otherwise invalid reviews.
Part 2 — Read paths and supporting structures
Walk through the read paths a course page needs (average rating and count, a paginated review feed sorted by recency or by helpfulness) and design the indexes or precomputed structures that serve each one without scanning every review on every request. Cover how an edit or a moderation action keeps those supporting structures correct.
Hints
Hint 1
Decide which existing row proves a learner actually finished the course, and let the review table's foreign key and uniqueness constraint hang off that row rather than off the learner or course alone.
Hint 2
List every screen that shows a rating or a review before drawing a single index — each one tells you what to index or precompute.
Hint 3
An average rating recomputed from every review on each page view doesn't scale; decide what maintains a running aggregate and when.
Hint 4
Work out what an edit or a moderation takedown has to update besides the review row itself.
Follow-up questions
- How would the schema change to support an instructor's public reply to a single review?
- How would you handle a learner who completes the same course twice and wants their newer review to replace the older one in the displayed average?
- What would you add to detect and suppress review-bombing from a coordinated set of accounts?
- How would you shard course_reviews if a handful of extremely popular courses dominate write volume?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.