The brief
Deliver timely, preference-aware messages across email, push, and SMS. Your design should meet these requirements:
- Product services can submit notifications through a common interface.
- Users can manage channel preferences and quiet hours.
- Temporary provider failures do not silently lose important messages.
Scale to design for
Many internal services send notifications via push, email, SMS. Millions per hour with bursts; some are critical (security codes), many are marketing. Providers have rate limits and outages.
State these assumptions out loud in the interview, then let them drive your choices: they decide what needs caching, sharding or asynchronous processing.
Before you start
You'll get more out of this round if you're comfortable with:
- Message queues and workers
- Retries with backoff
- Idempotency keys
- Push, email, and SMS providers
Questions an interviewer may ask
Expect follow-ups like these once your high-level design is on the board. Have an answer, and a reason, for each:
- How do you guarantee a 2FA code isn't delayed by a marketing campaign?
- What happens when the SMS provider is down for 20 minutes?
- How are duplicates prevented on retries?
- How do you track delivery?
Common mistakes to avoid
- A single queue for everything
- Synchronous provider calls in the API request
- No dedupe causing duplicate texts
- Dropping messages on provider errors
- Ignoring opt-outs (legal risk)
Concepts this round covers
- Fan-out and prioritization
- Retries and deduplication
- Provider quotas
- Messaging
What a complete answer covers
An intake, preference, queue, and delivery architecture with clear retry, idempotency, priority, and provider-failure behavior.
There is no single correct design. A strong answer meets the requirements at the stated scale and explains the trade-offs behind each choice. New to the format? Read how to prepare for a system design interview.