EvalcueAISystem design problem
Design a Notification Service
Design a platform that sends push, email, and SMS notifications at scale. This problem tests asynchronous processing, fan-out, provider abstraction, user preferences, retries, rate limits, idempotency, and observability.
Clarify channels, urgency, and delivery semantics
Ask which channels are supported, whether messages are transactional or bulk, required ordering, delay tolerance, user preferences, quiet hours, templates, localization, deduplication, and whether delivery is at-most-once or at-least-once.
- Push, email, and SMS
- Transactional versus bulk traffic
- Preferences and quiet hours
- Priority and delivery expectations
Use asynchronous fan-out and provider adapters
A notification API should validate and persist intent quickly, then queues and workers can expand recipients, render templates, apply preferences and rate limits, and call channel-specific providers without blocking the producer.
- Notification API
- Queue or event bus
- Channel-specific workers
- Provider abstraction and fallback
Design retries without duplicate user impact
Discuss idempotency keys, retry schedules, dead-letter queues, provider throttling, per-user limits, delivery status, webhook processing, partial provider outages, and observability across the end-to-end pipeline.
- Idempotent delivery attempts
- Exponential backoff and DLQ
- Provider rate limits
- Delivery tracking and alerting
Common questions
Why use queues in a notification service?
Queues decouple producers from slower external providers, absorb bursts, enable retries, and let different channels scale independently without making the caller wait for final delivery.
How do you avoid duplicate notifications?
Use stable notification or idempotency identifiers, make state transitions atomic, and ensure retried worker operations can recognize an already completed delivery attempt.
How should provider failures be handled?
Retry transient failures with backoff, respect provider rate limits, use dead-letter handling for repeated failures, and consider a secondary provider only when product requirements justify the complexity.