Design a Social-Media Comments and Notifications System

Design a comments section for posts in a social-media application with fewer than one million users. Authentication, users, and posts already exist. Cover comment APIs, database design, notifications, and how server and database resources would scale with reads and writes. ### Constraints & Assumptions - Reuse existing identity and post ownership; do not redesign login or the post system. - Clarify replies, edits, deletion, ordering, and notification recipients before finalizing the schema. - The user-count ceiling is given, but request rate, activity distribution, and latency targets are not. Estimate them from explicit assumptions if needed. ### Clarifying Questions to Ask - Are replies one level deep or arbitrarily nested? - Should deleting a parent also delete replies, or leave a tombstone? - Which actions notify the post author, parent-comment author, or mentioned users? - Are comments ordered chronologically, by relevance, or both? ### Part 1 — APIs and storage Define create, list, edit, and delete behavior, including authorization and pagination. #### What This Part Should Cover - Comment IDs, post and author references, reply relationships, timestamps, and edit/delete state. - Stable pagination with indexes matching the chosen order. - Permission checks and idempotent creation after client retries. ### Part 2 — Notifications Describe how a committed comment produces notifications without making the comment write depend on every downstream delivery. #### What This Part Should Cover - Recipient selection, duplicate suppression, user preferences, and durable event handling. - Separation of persisted notification state from push/email delivery attempts. - Recovery after failures between comment commit and event publication. ### Part 3 — Scaling reads and writes Explain where to add capacity and how to diagnose a hot post or overloaded database. #### What This Part Should Cover - Stateless application capacity, bounded queries, caching, and read replicas where appropriate. - Write-path contention, indexes, hot-key behavior, and cache invalidation. - Metrics that distinguish a server bottleneck from database or notification backlog pressure. ```hint Follow the successful create boundary A comment can be durably created even if a push notification fails. Give the comment and notification paths compatible retry identities without coupling their availability. ``` ### What a Strong Answer Covers - A design scoped to the existing user/post platform and the supplied population bound. - APIs, database indexes, notifications, and resource-scaling choices that support the same semantics. - Clear handling of retries, deletion, and concentrated traffic on one post. ### Follow-up Questions - How would you prevent duplicate notifications after an event is delivered twice? - What changes when a single post receives most of the read traffic?