Design an Extensible Multi-Channel Notification System
Company: Omnissa
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
# Design an Extensible Multi-Channel Notification System
Design the class structure and component interactions for a notification system. It initially supports email and SMS, but an interviewer may add channels, user preferences, templates, priority levels, retries, or scheduled delivery during the discussion.
Show how the design absorbs these changes without rewriting the core orchestration logic. Discuss both low-level interfaces and the service-level reliability boundary.
### Clarifying Questions to Ask
- Which channels and delivery guarantees are required initially?
- Are notifications transactional, promotional, or both, and do regulations affect opt-out behavior?
- Must callers receive a synchronous delivery result or only durable acceptance?
- How are templates, locales, priorities, schedules, and per-user preferences represented?
### What a Strong Answer Covers
- Clear message, recipient, template, channel, policy, provider, and delivery-attempt abstractions.
- Dependency inversion and registries or factories that add a channel without changing orchestration branches.
- Preference and consent checks, idempotency, durable queues, retries, backoff, and dead-letter handling.
- Provider failover, rate limits, observability, audit history, scheduling, and requirement-change examples.
### Follow-up Questions
1. Add mobile push notifications with multiple devices per user. Which interfaces change?
2. How would you guarantee that an order confirmation is accepted once but may safely be delivered after a worker retry?
3. How would you prevent a promotional campaign from delaying password-reset messages?
Overview: Design an extensible notification system with clean channel, template, policy, provider, and delivery-attempt abstractions. The solution shows how to add requirements safely while handling preferences, idempotency, durable queues, retries, priorities, scheduling, provider failures, auditability, and observability.
Read the full Omnissa Software Engineer interview experience this question came from