Push notification integration in HLD - System Design Exercise

Design: Push Notification Integration System

Design covers backend push notification service integration, message queuing, scheduling, and delivery tracking. Client-side SDKs and UI are out of scope.

Functional Requirements

FR1: Send real-time push notifications to mobile and web clients

FR2: Support both Android (Firebase Cloud Messaging) and iOS (Apple Push Notification Service)

FR3: Allow targeting notifications to individual users or user groups

FR4: Handle up to 100,000 concurrent notifications per minute

FR5: Ensure delivery latency under 2 seconds for 95% of notifications

FR6: Provide retry mechanism for failed deliveries

FR7: Allow scheduling notifications for future delivery

FR8: Support message personalization with user-specific data

Non-Functional Requirements

NFR1: System must be highly available with 99.9% uptime

NFR2: Notifications must be secure and respect user privacy

NFR3: API response time for sending notification requests must be under 200ms

NFR4: System should be scalable to handle peak loads during events

NFR5: Must comply with platform-specific push notification limits and guidelines

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

API Gateway for receiving notification requests

Authentication and Authorization service

Message Queue for decoupling and buffering notifications

Scheduler for delayed or recurring notifications

Push Notification Service Integrations (FCM, APNs)

Database for user device tokens and preferences

Monitoring and Logging system

Design Patterns

Producer-Consumer pattern for message queuing

Circuit Breaker pattern for external push service calls

Retry and Backoff strategies for failed deliveries

Fan-out pattern for sending notifications to multiple devices

Event-driven architecture for scheduling and delivery

Reference Architecture

  +-------------+       +----------------+       +-------------------+       +------------------+
  |  Client App | <---> | API Gateway    | <---> | Auth Service      |       | User Database    |
  +-------------+       +----------------+       +-------------------+       +------------------+
                                |                        |                          |
                                v                        |                          |
                         +----------------+             |                          |
                         | Notification    |             |                          |
                         | Service        |             |                          |
                         +----------------+             |                          |
                                |                        |                          |
                                v                        |                          |
                         +----------------+             |                          |
                         | Message Queue  | <-----------+                          |
                         +----------------+                                        |
                                |                                                   |
                                v                                                   |
                      +---------------------+                                       |
                      | Scheduler Service    |                                       |
                      +---------------------+                                       |
                                |                                                   |
                                v                                                   |
          +----------------+          +----------------+          +----------------+
          | FCM Service    |          | APNs Service   |          | Monitoring &   |
          | (Android)     |          | (iOS)          |          | Logging       |
          +----------------+          +----------------+          +----------------+

Components

API Gateway

RESTful API server (e.g., Node.js/Express, Spring Boot)

Receives notification requests from clients and forwards them after validation

Authentication Service

OAuth 2.0 / JWT

Validates client identity and permissions for sending notifications

Notification Service

Microservice (e.g., Python/Flask or Go)

Processes requests, applies business logic, and enqueues messages

Message Queue

Apache Kafka or RabbitMQ

Buffers notification messages for asynchronous processing and delivery

Scheduler Service

Cron jobs or distributed scheduler (e.g., Quartz, AWS EventBridge)

Handles scheduled and delayed notifications

Push Notification Services

Firebase Cloud Messaging (FCM), Apple Push Notification Service (APNs)

Delivers notifications to Android and iOS devices respectively

User Database

Relational DB (PostgreSQL) or NoSQL (DynamoDB)

Stores user device tokens, preferences, and opt-in status

Monitoring and Logging

Prometheus, Grafana, ELK Stack

Tracks delivery success, failures, latency, and system health

Request Flow

1. Client app sends a notification request to API Gateway with authentication token.

2. API Gateway forwards request to Authentication Service to verify permissions.

3. Upon success, Notification Service validates and enriches the message (personalization, scheduling).

4. Notification Service pushes the message to the Message Queue.

5. Scheduler Service picks scheduled messages from the queue at the right time.

6. Scheduler or Notification Service consumes messages from the queue and calls respective push services (FCM/APNs).

7. Push services deliver notifications to user devices.

8. Delivery status and errors are logged and monitored for retries if needed.

Database Schema

Entities: - User: user_id (PK), name, email - Device: device_id (PK), user_id (FK), device_token, platform (Android/iOS), is_active - Notification: notification_id (PK), user_id (FK), message, status, scheduled_time, created_at - UserPreferences: user_id (PK, FK), opt_in (boolean), preferred_language Relationships: - One User can have multiple Devices - One User can have multiple Notifications - UserPreferences linked one-to-one with User

Scaling Discussion

Bottlenecks

Message Queue saturation under high notification volume

Push service rate limits from FCM and APNs

Database read/write load for user tokens and preferences

Scheduler service delays with large scheduled notification backlog

API Gateway becoming a bottleneck under heavy request load

Solutions

Partition and scale message queue clusters horizontally; use topic partitioning by user segments

Implement rate limiting and batching to comply with push service limits; use multiple push service credentials if allowed

Use caching (e.g., Redis) for frequently accessed user tokens and preferences to reduce DB load

Distribute scheduling workload across multiple scheduler instances with sharding

Deploy API Gateway behind load balancers and use autoscaling to handle traffic spikes

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.

Emphasize asynchronous processing with message queues for reliability and scalability

Discuss handling platform-specific push notification services and their limits

Highlight importance of user preferences and opt-in management for privacy

Explain retry and failure handling strategies

Mention monitoring and alerting for operational health