Grokking the System Design Interview, Volume II
Vote

0% completed

​

Notification System: Requirements

Step 2: Clarify and Define Requirements

Functional Requirements (Features):

Non-Functional Requirements (Scale, Performance, Constraints):

Step 2: Clarify and Define Requirements

Before designing, let's clarify what this notification service must do and the constraints it must meet.

Functional Requirements (Features):

Functional requirements
Functional requirements
  • Multi-Channel Delivery: Support delivering notifications via email, SMS, mobile push, and in-app channels. Every notification event can be routed to one or multiple channels as appropriate.
  • Real-Time & Batched Notifications: Handle both immediate event-driven notifications and bulk or scheduled notifications. Real-time notifications (e.g. a chat message or alert) should be delivered within ~1-2 seconds to the user. The system also supports batching use cases - for instance, an app might schedule a daily digest or a marketing campaign to millions of users at once. This requires efficient bulk dispatch (possibly by scheduling or trigger-based batch jobs) in addition to one-off, on-demand sends.
  • Message Scheduling: Allow notifications to be scheduled for future delivery (e.g., a reminder set to go out at a specific time). Instead of immediate dispatch, such requests are stored and sent at the correct time via a scheduler component. For example, a meeting reminder can be queued to send 10 minutes before the event.
  • Retry on Failure: Implement retry mechanisms for failed deliveries. If a notification fails to send on a channel (due to transient errors such as provider downtime or network issues), the system should retry sending after a short delay, possibly with exponential backoff. This ensures at-least-once delivery - the system will make multiple attempts so that temporary issues don't cause message loss.
  • User Preferences & Opt-Out: Respect user notification preferences. The system should check if the user has unsubscribed or opted out of certain notification types or channels. For example, if a user disabled SMS notifications or opted out of promotional emails, the system must honor that and skip those channels. It should also support user-specific settings like preferred channels for certain alert types (e.g. critical alerts via SMS, newsletters via email).
  • Multi-Tenant Support: The service must isolate tenants' data. Each tenant can only access and send notifications to its own users.
  • Notification Content & Templates: Support customizable content for notifications. Tenants (or their product teams) should be able to define message templates for each notification type, possibly with placeholders (e.g., "Hello {name}, your order {order_id} shipped."). The service will fill in event-specific data.
  • No Channel Prioritization: All supported channels are treated equally by the system. If an event triggers notifications on multiple channels, each is delivered independently without prioritizing one over the other.
  • In-App Notification Management: Support in-app messaging - notifications that appear within the application's UI (e.g., the notification bell 🔔 in a social app). This implies the system will store notifications in a database so that a user can fetch their notification list. It can also push in-app alerts in real-time to active user sessions (via WebSocket or similar).
  • API for Notification Producers: Provide clean APIs or endpoints that various applications (social media, e-commerce, productivity tools, etc.) can call to create notification requests. Each request includes details like the user(s) to notify, the content (possibly a template ID and data), and which channel(s) to use. The API should handle single-recipient notifications as well as bulk sends (e.g., specifying a list of users or a user segment for broadcast).

Non-Functional Requirements (Scale, Performance, Constraints):

Non-functional requirements
Non-functional requirements

  • Scalability: The system should handle web-scale load. This means potentially millions of users and high notification volumes:

    • For a social media tenant, there could be hundreds of millions of notifications per day.
    • The design should scale horizontally (add more machines to handle more load) without any bottlenecks.

  • High Throughput: Support very high write and read rates. For example, the system might ingest tens of thousands of notification events per second during peak (imagine a viral post generating notifications or a major sale event).

  • Low Latency: Especially for real-time channels, end-to-end latency (from event to user device) should be low (ideally under a second). Email/SMS can tolerate slight delays (e.g., < 1 minute).

  • High Availability: The service should be reliable - aiming for minimal downtime (e.g., 99.99% uptime). Notifications can be critical (password resets, security alerts, order confirmations), so the system must be redundant and fault-tolerant across data centers or AZs (Availability Zones).

  • Durability: No lost notifications. Once an event is accepted, it should be queued/stored so that even if servers crash, the notification will eventually be delivered.

  • Ordering: Within a single user's notification feed, the system should maintain chronological order (at least eventual consistency in order). If two events for the same user occur, they should not appear out-of-order in the in-app feed. (Exact global ordering across the whole system is not required.)

  • Multi-Tenant Isolation & Security: One tenant's heavy load or failure should not cascade to others. We may need to enforce per-tenant rate limits or partitioning. Data must be partitioned or tagged by tenant so that it's impossible for tenant A to access tenant B's notifications or user info. Also, ensure secure authentication for tenants calling the API.

  • Flexibility & Extensibility: It should be easy to add new channels (say, WhatsApp or push for a new platform) without redesigning the whole system. Similarly, adding new features like notification scheduling (send at a specific time) or batching (daily digests) in the future should be possible.

With these requirements, we have a clear target. We need a fast, reliable notification service that handles all tenants' events, delivers on the appropriate channels, and respects user preferences at massive scale.

Next: Step 3, where those requirements become numbers.

On This Page

Step 2: Clarify and Define Requirements

Functional Requirements (Features):

Non-Functional Requirements (Scale, Performance, Constraints):