Notification service design

Overview

A notification service sends messages to users over channels such as email, SMS, push, and in-app, based on events (order shipped, password reset). The LLD focuses on clean abstractions: a Channel interface with provider adapters, templates rendered with data, user preferences (opt-outs, quiet hours), priority, retries with fallback providers, and delivery tracking.

Patterns fit naturally: Strategy/Adapter for channels and providers, Template Method or template engines for content, Observer or event subscriptions for triggers, Chain of Responsibility for preference and rate-limit checks, and Decorator for retries and logging.

When to use it

• Interview prompt: 'Design a notification system'.
• Any product sending transactional or marketing messages.
• Multi-provider messaging with failover.

Where it shows up in interviews

Where it is used in real software

Key terms

Channel

Delivery medium: email, SMS, push, in-app.

Provider

Vendor implementing a channel (SES, Twilio).

Template

Content with placeholders rendered per user.

Preference

User opt-ins, quiet hours, channel choices.

Delivery status

Queued, sent, delivered, failed.

How it works, step by step

1. 1
   Define the request

   userId, type, data, priority.

2. 2
   Resolve preferences

   Which channels are allowed now.

3. 3
   Render the template

   Per channel and locale.

4. 4
   Send via channel providers

   With retries and fallback.

5. 5
   Record status

   For deduplication, audit, and analytics.

Routing decisions

Different notification types

Priority and preferences are policy data, not hard-coded branches in senders.

Implementation

1type ChannelName = "email" | "sms" | "push";2type Message = { to: string; subject?: string; body: string };3 4interface Channel { name: ChannelName; send(msg: Message): Promise<void> }5 6class FallbackChannel implements Channel {7  constructor(readonly name: ChannelName, private providers: Channel[]) {}8  async send(msg: Message) {9    let lastError: unknown;10    for (const p of this.providers) {11      try { return await p.send(msg); } catch (e) { lastError = e; }12    }13    throw lastError;14  }15}16 17type Prefs = { channels: ChannelName[]; quietHours?: [number, number]; contact: Record<ChannelName, string> };18type Request = { eventId: string; userId: string; type: string; priority: "critical" | "normal" | "low"; data: Record<string, string> };19 20class NotificationService {21  private sent = new Set<string>();22  constructor(23    private channels: Map<ChannelName, Channel>,24    private prefs: (userId: string) => Promise<Prefs>,25    private templates: (type: string, channel: ChannelName, data: Record<string, string>) => Message["body"],26    private hour = () => new Date().getHours(),27  ) {}28 29  async notify(req: Request) {30    const p = await this.prefs(req.userId);31    const quiet = p.quietHours && this.hour() >= p.quietHours[0] && this.hour() < p.quietHours[1];32    const targets = p.channels.filter((c) => req.priority === "critical" || !(quiet && c === "push"));33    await Promise.allSettled(targets.map(async (c) => {34      const key = `${req.eventId}:${c}`;35      if (this.sent.has(key)) return;                               // idempotent per event and channel36      await this.channels.get(c)!.send({ to: p.contact[c], body: this.templates(req.type, c, req.data) });37      this.sent.add(key);38    }));39  }40}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Hard-coded channel logic in business services.

  Fix: Services publish events; the notification service decides channels.

• Ignoring user preferences and regulations.

  Fix: Honor opt-outs and quiet hours; required for compliance.

• Duplicate sends on retry.

  Fix: Deduplicate by event ID and channel.

Interview questions

Practice problems