Requirements

Let's design a push notification service. This service will be responsible for delivering notifications to various devices (e.g., iOS, Android, Web) using different push notification providers (e.g., APNs, FCM, WebPush). The key challenge lies in abstracting away the complexities of these different providers and offering a unified interface for sending notifications. We aim for a design that is extensible, allowing us to easily add new providers and notification types in the future. Our focus is on the core notification sending process and ensuring its reliability. # Requirements ## Functional Requirements 1. **Send a Notification:** The service must be able to send a notification to a specific user or a group of users. 2. **Support Multiple Device Platforms:** The service should support sending notifications to iOS, Android, and Web devices. Each device can be registered with multiple push notification tokens. 3. **Support Different Notification Types:** The service should support different types of notifications (e.g., simple text notifications, rich media notifications, transactional notifications). The payload format should be flexible enough to accommodate varying data requirements. 4. **Provider Abstraction:** The service must abstract away the complexities of different push notification providers (APNs, FCM, WebPush) and provide a unified interface for sending notifications. 5. **Delivery Status Tracking:** The service should track the delivery status of each notification (e.g., sent, delivered, failed). The status should be stored persistently. 6. **Retry Mechanism:** Implement a retry mechanism for failed notification deliveries with exponential backoff. 7. **Rate Limiting:** Implement rate limiting to prevent abuse and protect the notification providers from being overwhelmed. Rate limiting should be configurable per user/application. 8. **Configuration Management:** The service should have a flexible configuration system, allowing easy configuration of API keys, endpoints, and other provider-specific settings. 9. **Scheduling Notifications:** The system must be able to schedule notifications for delivery at a later time. 10. **Template Support:** The system should support using templates for notification content, allowing for dynamic content generation. ## Non-Functional Requirements 1. **Extensibility:** The design should be easily extensible to support new device platforms, notification types, and push notification providers with minimal code changes. The Open/Closed Principle should be heavily considered. 2. **Modularity:** The service should be modular, with clear separation of concerns between different components (e.g., provider abstraction, notification formatting, delivery management). 3. **Testability:** The components should be designed to be easily testable, both in isolation and in integration. 4. **Thread Safety:** The service must be thread-safe, as it will be handling concurrent requests from multiple clients. Specifically focus on thread safety related to updating/reading notification statuses and rate limiting. 5. **Resilience:** The service should be resilient to failures. Implement circuit breaker pattern for handling provider outages. 6. **Configuration:** Ensure that configuration settings can be easily modified without requiring application restarts. Consider externalized configuration. 7. **Performance:** While low latency is important, focus on throughput and scalability of notification delivery. Minimize blocking operations. 8. **Observability:** Implement comprehensive logging and monitoring to track the health and performance of the service. Metrics for notification delivery rates, error rates, and provider latency should be included. ## Core Entities 1. **`Notification`:** Represents a notification to be sent. Attributes: `notificationId`, `userId`, `type`, `payload`, `status`, `scheduledTime`. 2. **`UserDevice`:** Represents a user's device and its associated push notification token. Attributes: `userId`, `deviceId`, `platform`, `pushToken`. Note: One user can have many devices. 3. **`NotificationProvider`:** An interface for interacting with different push notification providers (APNs, FCM, WebPush). Methods: `send(Notification, UserDevice)`, `getStatus(Notification)`. 4. **`APNsProvider`, `FCMProvider`, `WebPushProvider`:** Implementations of the `NotificationProvider` interface for specific providers. 5. **`NotificationService`:** The main service for sending notifications. It orchestrates the process of selecting the appropriate provider, formatting the notification, and tracking delivery status. 6. **`NotificationScheduler`:** Responsible for scheduling notifications for delivery at a later time. 7. **`RateLimiter`:** Responsible for limiting the number of notifications sent to a user or application within a specific time period. 8. **`DeliveryStatusTracker`:** Component responsible for updating and retrieving the delivery status of notifications. 9. **`TemplateEngine`:** Responsible for populating templates with dynamic content for the notification payload.

Design push notification :

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content