Design a Multi-Channel Notification Dispatcher for a Global Ride & Logistics Platform
Our global logistics platform connects 500 million riders and drivers. Dozens of backend services send critical notifications (e.g., driver arrival, trip status, billing receipts) and promotional messages. Currently, each backend team integrates directly with third-party vendors (Twilio, FCM, APNs, SendGrid), causing inconsistent user preferences, missing quiet-hour controls, duplicate alerts during retries, and high vendor costs. You are asked to design a centralized Multi-Channel Notification Platform that abstracts channel delivery across Push, SMS, Email, and In-App inbox. The system must process upstream requests, evaluate user notification preferences and quiet hours, deduplicate messages, enforce provider rate limits, and implement multi-step fallback strategies (such as falling back to SMS if a critical Push notification is unconfirmed after 30 seconds).
- Ingest notification dispatch requests from upstream microservices via API and event stream.
- Enforce user preferences including channel opt-ins per alert category and timezone-aware quiet hours.
- Support multi-channel delivery (iOS APNs, Android FCM, SMS, Email, In-App Inbox) with multi-vendor failover.
- Implement delayed fallback policies (e.g., send Push first; if unacknowledged within 30s, trigger SMS fallback for critical alerts).
- Maintain a queryable status lifecycle (Queued, Dispatched, Delivered, Failed, Read) and surface an In-App Inbox feed.
- Process 50,000 peak notifications per second with under 1 second p99 dispatch latency for critical alerts.
- Guarantee at-least-once delivery for transactional alerts while maintaining strict idempotency to prevent duplicate customer messages.
- Isolate low-priority promotional traffic from high-priority transactional alerts so queue backpressure never delays trip updates.
- Enforce per-user spam throttling and respect vendor-specific outbound rate limits.
500 million total registered users, 100 million daily active users. 2 billion notifications per day (~23,000 avg/sec, 50,000 peak/sec). Notification metadata payload size is ~1 KB, producing ~2 TB of notification state data per day.
- High-level architecture diagram depicting ingestion, preference routing, job scheduling, worker pools, status tracking, and provider integrations.
- Data models for Notification Jobs, User Preferences/Rules, and Delivery Receipts/Inbox Storage.
- Detailed workflow and component design for time-based channel fallback (e.g., Push-to-SMS fallback timeout).
- Strategy for provider-level rate limiting, deduplication, and queue isolation between alert priorities.
Strong designs show how user preference rules and quiet hours are evaluated efficiently at scale. They utilize fast lookup caches (e.g., Redis) backed by persistent storage, account for user timezones, handle rule deferrals vs. drops for delayed alerts, and avoid querying database instances on every incoming message.
Strong answers define a clear strategy using deduplication keys (combining user_id, event_type, and window timestamp). They detail a distributed lock or atomic cache check-and-set mechanism before worker execution to guarantee customers never receive duplicate SMS or Push messages during upstream retries.
Strong designs avoid naive database polling to check unacknowledged deliveries. Instead, they present a scalable delayed execution pattern (e.g., delayed message queues, hierarchical timing wheels, or dead-letter queue TTLs) that triggers fallback channels only when delivery callbacks (APNs/FCM receipts) are not received within the SLA window.
Strong answers separate queues by priority (e.g., transactional vs. marketing) and channel. They incorporate token-bucket or leaky-bucket rate limiters in front of third-party SMS/Push APIs to respect vendor quotas and prevent account suspension.
Strong answers propose a scalable partition strategy (e.g., sharded NoSQL database partitioned by user_id) for storing delivery receipts and the customer in-app inbox feed. They address write-heavy workloads, retention/TTL policies, and efficient pagination for in-app views.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: If a major SMS vendor experiences a 15-minute outage in a specific region, how does your system detect this failure, reroute traffic to a secondary vendor without exceeding secondary quotas, and prevent queue backpressure from impacting real-time Push alerts?
The whiteboard design must show end-to-end data flow from API ingestion to external provider dispatch, highlighting state management and rate limiting. Focus on architecture, queue topologies, data models, and trade-offs — do not write code or function signatures.
- Views
- 9