Design a notification system

Quick Overview

This question evaluates a candidate's competency in designing scalable, reliable multi-channel notification platforms, covering distributed systems, multitenancy, API and storage schema design, queuing and retry strategies, rate limiting, observability, localization, A/B testing, and compliance considerations like GDPR.

Design a notification system

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a notification system that sends messages via email, SMS, and push. Support real-time and scheduled delivery, per-user preferences and quiet hours, deduplication and idempotency, retries with exponential backoff, rate limiting (per user and per provider), multi-tenant isolation, and templating/localization. Provide APIs, storage schema, queue/pub-sub design, worker orchestration, provider integration, and monitoring/alerting. Discuss scalability targets (e.g., p99 latency, TPS), failure modes, exactly-once vs at-least-once semantics, A/B testing, GDPR/compliance, and cost controls.

Quick Answer: This question evaluates a candidate's competency in designing scalable, reliable multi-channel notification platforms, covering distributed systems, multitenancy, API and storage schema design, queuing and retry strategies, rate limiting, observability, localization, A/B testing, and compliance considerations like GDPR.

|Home/System Design/DoorDash
DoorDash logo
DoorDash
Sep 6, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
29
0

System Design: Multi-Channel Notification Platform

Context

Design a multi-tenant notification platform that delivers messages across email, SMS, and mobile push. The system must support both real-time and scheduled notifications, per-user preferences, and be resilient, scalable, and cost-aware.

Functional Requirements

  1. Channels: email, SMS, push notifications.
  2. Delivery modes: real-time and scheduled (one-time and recurring).
  3. User controls: per-user preferences (opt-in/out per category), quiet hours, locale/time zone.
  4. Reliability: deduplication, idempotency, retries with exponential backoff.
  5. Throttling: rate limiting per user, per tenant, and per provider.
  6. Isolation: strict multi-tenant isolation (configs, limits, data segregation).
  7. Content: templating with variables, localization (i18n, l10n), and A/B testing support.
  8. Observability: monitoring, alerting, delivery analytics.
  9. Compliance: GDPR/data minimization, consent management, auditability.
  10. Cost controls: budgets/quotas and provider selection for cost/performance.

Non-Functional Requirements

  • High availability; horizontal scalability.
  • Message delivery latency targets and throughput (TPS) goals.
  • Delivery semantics: discuss exactly-once vs at-least-once.
  • Graceful degradation and failure-mode strategies.

Deliverables

  • Public APIs (send, schedule, templates, preferences, status).
  • Storage schema (entities, key indexes, partitioning).
  • Queue/pub-sub design and retry strategy.
  • Worker orchestration and provider integration patterns.
  • Monitoring/alerting and analytics plan.
  • Scalability targets (e.g., p99 latency, TPS) with reasoning.
  • Failure modes and mitigations.
  • A/B testing strategy.
  • GDPR/compliance approach.
  • Cost controls and budgets.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...