Design Comment System
starter
Start practice 🎤 Interview Simulation · Premium View reference solution
Practice steps
- Problem Statement, Functional Requirements, and Scale Assumptions
Define the Comment System scope: post-level comments with threaded replies, reactions (likes), and basic moderation (report spam). Clarify what counts as a comment thread (how many levels of nesting are supported), whether comments are attached to a generic content type or only posts, and whether anonymous commenting is in scope. State explicit non-goals: rich media embeds in comments, real-time collaborative editing, and direct messaging. Establish starting scale assumptions before proposing components. - Non-Functional Requirements
Choose NFRs appropriate for a comment system: the workload is read-heavy (fetching comment threads on popular posts) so read latency and availability are primary; comment creation can tolerate slightly higher latency than reads; comment counts can be eventually consistent. Address spam resilience -- the system must prevent comment flooding without degrading the read path. Decide on consistency requirements for thread ordering and pagination cursors. - Quantitative Analysis
Estimate key numbers: average comments per post, thread depth distribution, total comment store size per year, read QPS for fetching a popular post's comment thread versus write QPS for new comments, cache working set size for hot post comment pages, and storage per comment (ID, author, content, timestamps, parent reference). Quantify the read/write ratio and explain its implications for storage and caching choices. - API Design
Define the comment API operations: create a comment on a post (with optional parent_comment_id for replies), list comments for a post (paginated, with threading -- how do you return a tree in a flat API response?), edit a comment (owner only), delete a comment (soft delete vs. hard delete and how it affects child replies), react to a comment, and report a comment for spam. Include request and response shapes, pagination cursor design, and error cases. - High-Level Design
Propose the main components: comment service (create, list, edit, delete), comment store (relational or document store for threaded data), cache layer for hot post comment pages, notification service (alert parent comment author when a reply is posted), and spam filter (pre-store content scoring). Describe the hot read path for fetching a popular post's comment thread: where does caching apply, what data is denormalized, and how does pagination work for deep threads? - Additional High-Level Design Prompts
Clarify three design decisions: (1) Notification fan-out -- when a user posts a reply, the parent comment author and possibly the post author must be notified; at what volume does naive direct notification become a fan-out problem, and how do you handle a popular post with thousands of commenters? (2) Comment ranking and sorting -- should comments display chronologically, by top-level reaction count, or by reply count; how does sort order affect the pagination cursor design? (3) Soft delete versus hard delete -- when a parent comment is soft-deleted, what happens to its visible child replies in the UI, and how does your storage model represent this? - Deep Dives
Deep dive into three areas: (1) Threaded comment tree storage models -- compare adjacency list (each row stores parent_id; simple writes, recursive reads), materialized path (each row stores full ancestor path string like '1/4/7'; fast subtree reads, expensive moves), and nested set (each row stores left/right range values; range query reads, expensive insertions) -- cover query complexity, insertion cost, pagination within subtrees, and depth limit enforcement; (2) Real-time updates -- compare push (WebSocket or SSE for connected clients) versus poll (client polls every N seconds) for notifying users of new comments; discuss fan-out for viral posts with thousands of concurrent viewers and connection scaling; (3) Spam filtering -- design an automated content scoring pipeline (text heuristics, link detection, rate limiting comment creation per user and per IP) feeding into a threshold: below threshold auto-allow, above threshold auto-block or route to human review queue with prioritization. - Final Review Handoff Readiness
Summarize the end-to-end design: the thread storage model chosen and why, the caching strategy for hot post comment pages, the real-time update mechanism, the spam filtering approach, and the soft-delete behavior. Identify consistency trade-offs (e.g., eventual consistency for comment counts and reactions). Name the largest open risks (storage model migration cost if thread depth requirements change, fan-out bottleneck for viral posts, moderation queue backlog during spam attacks) and propose a moderation rollout plan.