Design scalable notification system
System Design: Low-Latency, Multi-Channel Notification Platform
You are asked to design a scalable, reliable notification system that can send messages to millions of users with low latency across multiple channels (email, SMS, push).
Assume a large, consumer-facing product operating globally with both transactional (real-time) and bulk/marketing use cases.
Cover the following:
-
Requirements Gathering
-
Functional, non-functional, traffic assumptions, SLAs/latency targets, compliance.
-
High-Level Architecture
-
Core components and data flow for real-time, scheduled, and bulk sends.
-
Data Model
-
Key entities (templates, preferences, messages, attempts, providers, etc.).
-
API Design
-
Producer APIs, admin APIs, idempotency, status callbacks/webhooks.
-
Message Prioritization
-
Priority levels, queueing, fairness, rate limits, quotas.
-
Deduplication
-
Idempotency keys, content-based dedup, time windows.
-
Retries and Failure Handling
-
Backoff, dead-letter queues, poison-pill handling, fallback channels, circuit breaking.
-
Scaling Strategies
-
Partitioning, horizontal scaling, multi-region, autoscaling triggers.
-
Monitoring and Alerting
-
SLIs/SLOs, metrics, logs, traces, runbooks.
-
Cost Considerations
-
Unit economics by channel, routing, batching, budgets, frequency caps.
State reasonable assumptions where needed and explain trade-offs.
Constraints & Assumptions
-
Preserve the scope, facts, inputs, and requested outputs from the prompt above.
-
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
-
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.
Clarifying Questions to Ask
-
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
-
State explicit assumptions before making sizing or architecture decisions.
-
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers
-
A scoped requirements summary with concrete non-goals and success metrics.
-
API, data model, architecture, consistency, capacity, and operations.
-
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
-
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions
-
What breaks first at 10x traffic or data volume?
-
How would you degrade gracefully during dependency failures?
-
What metrics and alerts would prove the design is healthy after launch?