# Design Comment Notifications with Viral-Pin Aggregation Design a system that sends a push notification to a pin owner when someone comments on the pin. For an ordinary pin, each eligible comment should create a notification. When a pin becomes viral and receives too many comments, the system should aggregate comments so that the owner receives only a limited number of notifications while still learning that activity continues. ### Constraints & Assumptions - A comment is durably stored before notification processing begins. - Push delivery may be retried and therefore must tolerate duplicate attempts. - The per-user notification limit and aggregation window are configurable policies. - The owner should not be notified for comments that are deleted before processing when that state is available. ### Clarifying Questions to Ask - Is the limit per pin, per owner, per device, or a combination? - How quickly must the first notification arrive, and how late may an aggregate arrive? - Should an owner commenting on their own pin generate a notification? ```hint Separate intent from delivery Persist a notification intent before calling an external push provider. ``` ```hint Aggregate with state Track a window, count, and last delivered aggregate rather than inspecting the full comment history each time. ``` ### What a Strong Answer Covers - An event-driven write path that keeps comment creation independent from push providers. - Idempotency, ordering, retry, and dead-letter behavior. - A concrete state machine for switching from individual to aggregated notifications. - Per-user preference, rate-limit, observability, and privacy considerations. ### Follow-up Questions - How would you prevent a notification storm when a previously offline consumer catches up? - How would the design support digest text such as '12 new comments' without losing the newest preview?