Katkat
Back

Design Comment Notifications with Viral-Pin Aggregation

PinterestSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

Tests end-to-end system design for large-scale, bursty notification pipelines, focusing on stream processing, aggregation under viral traffic spikes, and reliable third-party push delivery.

Scenario

At a visual discovery platform like Pinterest, creators and pinners share content that can suddenly go viral. When users leave comments on a pin, the author expects timely updates. However, for viral pins receiving tens of thousands of comments per minute, sending an individual push notification for every single comment would crash user devices, trigger aggressive OS rate limits, and degrade the user experience.

Design a resilient notification system that delivers comment notifications to pin authors while intelligently aggregating updates during viral spikes (e.g., collapsing notifications into "Alice and 14 others commented on your Pin").

Functional Requirements

  • Comment Notification Dispatch: Notify the pin creator whenever a user comments on their pin.
  • Smart Aggregation: Batch or aggregate high-frequency notifications for the same pin within a configurable time window (e.g., 5 to 15 minutes) instead of spamming individual pushes.
  • Notification Center & Read State: Store an inbox history of notifications with read/unread statuses accessible via an in-app feed.
  • User Preferences: Honor creator preferences (e.g., quiet hours, frequency caps, or opt-outs per pin/board).

Non-Functional Requirements

  • Low Latency for Normal Volume: Single, non-viral comments should notify the owner within 5 seconds.
  • High Availability & Fault Tolerance: No dropped notifications during transient failures; at-least-once processing semantics.
  • Scalability: Gracefully absorb extreme write spikes from viral pins without backpressuring comment creation.
  • Idempotency & Deduplication: Guard against duplicate notifications caused by network retries or distributed replay.

Scale Assumptions

  • Daily Active Users (DAU): 200 million.
  • Daily Comments: 100 million total comments per day (~1,200 comments/sec average, peaking at 10,000 comments/sec).
  • Viral Hotspots: A top 0.01% viral pin can receive 500+ comments/second for several consecutive hours.
  • Push Delivery: Average of 50 million push notifications sent per day.

Key Areas to Cover

  1. APIs: Endpoints for comment creation event triggers, fetching user notifications, and setting preferences.
  2. Data Model: Storage schemas for notification history, aggregation state, and user device mappings.
  3. Aggregation Engine: Mechanism (sliding windows, tumbling windows, or debounce queues) to detect viral activity and aggregate payloads.
  4. End-to-End Architecture: Pipeline from comment event emission through queueing, filtering, aggregation, push gateway (APNs/FCM) dispatch, and notification inbox storage.
  5. Failure Modes & Observability: Handling push service outages, consumer lag, and stale aggregation states.

Hints

Hint 1

Decouple the comment creation path from notification generation using an asynchronous message broker to prevent delivery issues from degrading the core comment API.

Hint 2

Use a stream processing framework or in-memory key-value store (like Redis) with a dynamic time-to-live (TTL) to manage tumbling or sliding aggregation windows per (author, pin) pair.

Hint 3

Maintain an idempotent dispatch mechanism keyed by an aggregation window ID or batch token to ensure retries do not result in duplicate push deliveries.

Follow-up questions

  • How would you dynamically adjust the aggregation window size based on real-time comment velocity on a specific pin?
  • If a commenter deletes their comment while the notification is sitting in an aggregation buffer, how should the system handle the final push content?
  • How do you isolate the blast radius of a hyper-viral pin so its message queue partition doesn't cause consumer lag for millions of normal pins?