Design a multi-channel notification system

Q: Design a multi-channel notification system

This question evaluates system design and distributed systems competencies—scalable architecture, API and schema design, idempotency and de-duplication, rate limiting, multi-region reliability, monitoring, and compliance for a multi-channel notification platform—and is commonly asked to assess the ability to balance latency, throughput, and operational trade-offs in production-grade services. Category: System Design; domain: distributed systems, reliability engineering, data modeling, and operational observability; level of abstraction: practical application with significant conceptual design considerations around delivery semantics, scalability targets, and regulatory constraints.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Airbnb.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Airbnb during technical interviews.

Question

System Design: Multi-Channel Notifications (Email, SMS, Push, In‑App)

Context

Design a notification platform that reliably delivers messages across multiple channels (email, SMS, mobile push, in‑app) while honoring user preferences and regulatory constraints. The system should scale to 10M notifications/day with p99 end-to-end processing latency under 2 seconds (to provider accept), support multi‑region reliability, and provide strong operational observability.

Requirements

APIs and Contracts
- Event production and consumption APIs (idempotent) for transactional and batch use cases.
- User preference APIs: per‑channel, per‑category, quiet hours (with timezone), daily caps.
- Templating and localization: variables, safe rendering, locale fallback.
- Idempotency and de‑duplication keys with TTLs.
- Scheduling (future send), retries with exponential backoff and jitter.
- Rate limiting: global, per‑channel, per‑recipient throttling.
- Delivery status tracking and unified state model.
Architecture & Components
- Producer, dispatcher/orchestrator, queues/streams, worker pools, provider adapters, metadata stores, rate limiter, scheduler, status tracker, analytics sink.
Data Models
- Notification request, user preferences, templates/variants, experiments, rate limits, delivery attempts/events, suppression lists.
Delivery Semantics
- Exactly‑once vs at‑least‑once trade‑offs and where to enforce idempotency/dedupe.
Reliability & Scale
- Targets: 10M/day, p99 < 2s to provider, burst handling, multi‑region (active/active or active/passive), failure handling, circuit breaking, DLQs.
Monitoring & Compliance
- Metrics, logs, traces, alerting; unsubscribe handling; GDPR/CCPA/consent/data‑retention.
Evolution Plan
- Experimentation (A/B), prioritization policies, cost controls and provider routing.

Provide a design with concrete APIs (REST or gRPC), schemas, component interactions, and operational playbooks. Call out assumptions where needed.

Design a multi-channel notification system

Quick Overview

Design a multi-channel notification system

System Design: Multi-Channel Notifications (Email, SMS, Push, In‑App)

Context

Requirements

Submit Your Answer to Earn 20XP