Real-time features in HLD - System Design Exercise

Design: Real-time Notification System

Design covers backend architecture, message delivery, subscription management, and client communication. Out of scope are UI design and third-party integrations.

Functional Requirements

FR1: Deliver notifications to users instantly when events occur

FR2: Support 100,000 concurrent users receiving notifications

FR3: Allow users to subscribe/unsubscribe to different notification types

FR4: Ensure message delivery order is preserved per user

FR5: Provide at-least-once delivery guarantee

FR6: Support web and mobile clients

Non-Functional Requirements

NFR1: Latency for delivering notifications should be under 200ms (p99)

NFR2: System availability should be 99.9% uptime

NFR3: Handle peak loads of 10,000 notifications per second

NFR4: Support horizontal scaling for growing user base

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Event producer or source

Message broker or queue system

Subscription management service

Notification delivery service

Client communication protocols (WebSocket, HTTP/2, Push APIs)

Cache or in-memory store for fast lookup

Database for persistence

Design Patterns

Publish-Subscribe pattern

Event-driven architecture

Message queue with topic partitions

Push notification protocols

Backpressure and rate limiting

Retry and dead-letter queue handling

Reference Architecture

  +----------------+       +------------------+       +---------------------+
  | Event Producer | ----> | Message Broker   | ----> | Notification Service |
  +----------------+       +------------------+       +---------------------+
                                   |                             |
                                   |                             v
                             +-------------+             +--------------+
                             | Subscription|             | Client       |
                             | Management  |             | Communication|
                             +-------------+             +--------------+

Components

Event Producer

Any backend service or external system

Generates events that trigger notifications

Message Broker

Apache Kafka or RabbitMQ

Queues and routes notification events to consumers

Subscription Management

Relational DB (PostgreSQL) + Cache (Redis)

Stores user subscriptions and preferences

Notification Service

Microservice in Node.js or Java

Processes events, checks subscriptions, sends notifications

Client Communication

WebSocket, HTTP/2 Push, or Firebase Cloud Messaging

Delivers notifications to web and mobile clients in real-time

Request Flow

1. 1. Event Producer creates a notification event and sends it to the Message Broker.

2. 2. Message Broker stores and routes the event to the Notification Service.

3. 3. Notification Service queries Subscription Management to find users subscribed to this event type.

4. 4. Notification Service sends notifications to clients via Client Communication protocols.

5. 5. Clients receive notifications instantly and display them to users.

Database Schema

Entities: - User (user_id, name, contact_info) - Subscription (subscription_id, user_id, notification_type, is_active) - NotificationEvent (event_id, type, payload, timestamp) Relationships: - User 1:N Subscription - NotificationEvent linked to multiple Subscriptions via notification_type This schema supports tracking which users receive which notifications.

Scaling Discussion

Bottlenecks

Message Broker throughput limits under high event volume

Notification Service CPU and memory under heavy processing

Subscription Management DB read latency for large user base

Client connections limit for WebSocket servers

Solutions

Partition topics in Message Broker and scale brokers horizontally

Deploy multiple instances of Notification Service with load balancing

Use caching (Redis) to reduce DB reads for subscriptions

Use multiple WebSocket servers with sticky sessions and load balancers

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain real-time delivery challenges and low latency needs

Discuss choice of message broker and pub-sub pattern

Highlight subscription management and filtering logic

Describe client communication protocols and fallback options

Address scaling bottlenecks and horizontal scaling strategies