Notification on state change in LLD - System Design Exercise

Design: Notification on State Change System

Design covers detection of state changes, notification dispatch, subscription management, and audit logging. Out of scope are the internal state management of entities and third-party notification service implementations.

Functional Requirements

FR1: Detect changes in the state of an entity (e.g., order status, device status).

FR2: Send notifications to users or systems when a state change occurs.

FR3: Support multiple notification channels (e.g., email, SMS, push notifications).

FR4: Allow users to subscribe or unsubscribe from notifications for specific state changes.

FR5: Ensure notifications are delivered reliably and in a timely manner.

FR6: Provide an audit log of all state changes and notifications sent.

Non-Functional Requirements

NFR1: Handle up to 10,000 state changes per minute.

NFR2: Notification delivery latency should be under 5 seconds for 95% of notifications.

NFR3: System availability should be at least 99.9% uptime.

NFR4: Support eventual consistency for notification delivery status.

NFR5: Ensure data privacy and security for user contact information.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

State Change Detector

Notification Dispatcher

Subscription Management Service

Notification Channels (Email, SMS, Push)

Audit Logging Service

Message Queue for decoupling

Database for storing subscriptions and logs

Design Patterns

Observer pattern for state change detection

Publish-Subscribe pattern for notification dispatch

Retry and dead-letter queue for failed notifications

Circuit breaker for external notification services

Event sourcing for audit logging

Reference Architecture

 +-------------------+       +-----------------------+       +---------------------+
 |                   |       |                       |       |                     |
 | State Change      |       | Subscription          |       | Notification        |
 | Detector          +------>+ Management Service    +------>+ Dispatcher          |
 |                   |       |                       |       |                     |
 +-------------------+       +-----------+-----------+       +----------+----------+
                                         |                              |
                                         |                              |
                                         v                              v
                              +-------------------+          +---------------------+
                              |                   |          |                     |
                              | Database          |          | Message Queue       |
                              | (Subscriptions,   |          | (Notification Jobs) |
                              | Audit Logs)       |          |                     |
                              +-------------------+          +----------+----------+
                                                                        |
                                                                        v
                                                      +-----------------------------+
                                                      |                             |
                                                      | Notification Channels        |
                                                      | (Email, SMS, Push)           |
                                                      |                             |
                                                      +-----------------------------+

Components

State Change Detector

Custom service or hooks in existing systems

Detects when an entity's state changes and emits events.

Subscription Management Service

REST API with database backend

Manages user subscriptions and preferences for notifications.

Notification Dispatcher

Worker service consuming from message queue

Processes notification jobs and sends notifications via channels.

Message Queue

RabbitMQ or Kafka

Decouples state change detection from notification sending for reliability and scalability.

Database

Relational DB like PostgreSQL

Stores subscriptions, audit logs, and notification statuses.

Notification Channels

Third-party APIs (SMTP, Twilio, Firebase Cloud Messaging)

Deliver notifications via email, SMS, and push notifications.

Audit Logging Service

Part of database or separate logging system

Records all state changes and notification delivery attempts.

Request Flow

1. 1. State Change Detector detects a change in an entity's state.

2. 2. It publishes a state change event to the Subscription Management Service.

3. 3. Subscription Management Service queries the database for users subscribed to this state change.

4. 4. For each subscribed user, it creates notification jobs and pushes them to the Message Queue.

5. 5. Notification Dispatcher consumes jobs from the Message Queue.

6. 6. Dispatcher sends notifications through the appropriate Notification Channels.

7. 7. Notification Dispatcher updates the notification status in the database.

8. 8. Audit Logging Service records the state change event and notification delivery details.

Database Schema

Entities: - User (user_id, contact_info, preferences) - Subscription (subscription_id, user_id, entity_type, state_change_type) - Notification (notification_id, subscription_id, state_change_event_id, status, timestamp) - StateChangeEvent (event_id, entity_id, old_state, new_state, timestamp) Relationships: - User 1:N Subscription - Subscription 1:N Notification - StateChangeEvent 1:N Notification

Scaling Discussion

Bottlenecks

High volume of state change events causing message queue overload.

Notification Dispatcher becoming a bottleneck under heavy load.

Database write contention for audit logs and notification statuses.

Latency in third-party notification channels causing delays.

Managing user subscription data growth.

Solutions

Partition message queue topics by entity type or region to distribute load.

Scale Notification Dispatcher horizontally with multiple worker instances.

Use batch writes and optimized indexing in the database; consider sharding audit logs.

Implement retries with exponential backoff and circuit breakers for third-party APIs.

Archive old subscription and audit data; use caching for frequently accessed subscription info.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 15 minutes designing the architecture and data flow, 10 minutes discussing scaling and trade-offs, and 10 minutes answering questions.

Clarify what state changes and notification channels are needed.

Explain how decoupling with message queues improves reliability and scalability.

Describe subscription management and user preference handling.

Discuss how audit logging supports traceability and debugging.

Address failure handling and retry mechanisms for notifications.

Highlight scaling strategies and bottleneck mitigation.