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.

What difficulty level is this interview question?

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

What role is this question designed for?

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

Design a multi-channel notification system

Quick Overview

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.

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.

Quick Overview

Context

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

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

Context

Requirements

Solution

Comments (0)

Design a multi-channel notification system

Quick Overview

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

Context

Requirements

Solution

Comments (0)