Problem and Scope
Design a notification service that can deliver real-time notifications to users across multiple devices while ensuring scalability and reliability.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Support push notifications to multiple types of devices (mobile, web, desktop)
- Allow users to subscribe to different topics or event types
- Deliver notifications in real-time to online users
- Store notifications for offline users to be delivered when they reconnect
- Support both individual user notifications and broadcast notifications to multiple users
- Allow for notification settings and preferences per user
Non-functional requirements:
- High availability: The system should be highly available as notifications are critical for user engagement
- Low latency: Notifications should be delivered in near real-time (within seconds)
- Scalability: The system should handle millions of users and billions of notifications per day
- Consistency: Users should not miss notifications or receive duplicates
- Fault tolerance: The system should continue to function even if some components fail
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- Support 100+ million active users
- Handle 1+ billion notifications per day
- Average notification size is around 100 bytes
- Some topics may have millions of subscribers
- Users may be subscribed to dozens of topics on average
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Notification ingestion service
- Fan-out mechanism for delivering notifications to multiple subscribers
- Real-time delivery system for online users
- Storage system for offline notifications
- Subscription management service
- Client SDK or integration points
- Monitoring and analytics system
- Efficiently delivering notifications to millions of users subscribed to popular topics
- Handling the "thundering herd" problem when many clients reconnect simultaneously
- Ensuring exactly-once delivery semantics to prevent duplicate notifications
- Managing device connectivity and state
- Optimizing storage for topics with millions of subscribers
- Balancing between push and pull models for notification delivery
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would you handle the fan-out problem for topics with millions of subscribers?
- Focus: Assess the candidate's answer to "How would you handle the fan-out problem for topics with millions of subscribers" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What strategies would you use to ensure notifications are delivered exactly once?
- Focus: Assess the candidate's answer to "What strategies would you use to ensure notifications are delivered exactly once" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your system scale if the number of users or notifications increased by 10x?
- Focus: Assess the candidate's answer to "How would your system scale if the number of users or notifications increased by 10x" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What trade-offs would you consider between push and pull models for notification delivery?
- Focus: Assess the candidate's answer to "What trade-offs would you consider between push and pull models for notification delivery" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would you handle the case where a user has multiple devices?
- Focus: Assess the candidate's answer to "How would you handle the case where a user has multiple devices" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What mechanisms would you implement to handle temporary failures in the system?
- Focus: Assess the candidate's answer to "What mechanisms would you implement to handle temporary failures in the system" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Support push notifications to multiple types of devices (mobile, web, desktop); Allow users to subscribe to different topics or event types; Deliver notifications in real-time to online users. Establishes the constraints that materially affect Design Notification System, including High availability: The system should be highly available as notifications are critical for user engagement; Low latency: Notifications should be delivered in near real-time (within seconds). Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Notification ingestion service; Fan-out mechanism for delivering notifications to multiple subscribers; Real-time delivery system for online users; Storage system for offline notifications. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as Support 100+ million active users; Handle 1+ billion notifications per day to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Storage system for offline notifications; Optimizing storage for topics with millions of subscribers; Balancing between push and pull models for notification delivery. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Monitoring and analytics system; High availability: The system should be highly available as notifications are critical for user engagement; Consistency: Users should not miss notifications or receive duplicates. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Managing device connectivity and state; Optimizing storage for topics with millions of subscribers; Balancing between push and pull models for notification delivery. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.