How would you design a company-wide notification service?

Question

IT Interview Practice · Accepted Answer

Build one service that every team calls with a **notification type + recipient**, and let the service resolve channel, template, user preferences, and priority. The key design move is **priority lanes** — an OTP cannot wait behind a 2M-user marketing blast.

## Architecture

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## Components and flow

- **Notify API** takes a typed request: `{type: "otp", user, data}`. Callers never pick a channel or write copy — the service owns that, so a template change ships once.
- **Type → policy**: each **type** maps to a policy. *OTP* is high-priority, SMS+Push, ignores marketing opt-out, expires in 60s. *Transactional* (receipt, password reset) is high, respects channel prefs. *Marketing* is low, bulk lane, strictly honors opt-out and quiet hours.
- **Priority lanes** are separate Kafka topics with separate consumer groups. The high lane stays near-empty and drains in milliseconds; the bulk lane can back up for minutes without touching OTP latency. This is the single most important decision.
- **Preference service** is checked per recipient: opted out? quiet hours? per-channel toggle? frequency cap? Marketing that violates a preference is dropped here.
- **Template engine** renders localized content from a versioned template + variables, so copy and code are decoupled.
- **Channel adapters** wrap FCM/APNs, SendGrid, Twilio behind one interface, each with its own rate limiter, retry, and DLQ (same fan-out discipline as any bulk sender).

## Interview perspective

Interviewers probe whether you separate **concerns**: many candidates build a monolith that sends email directly, then discover marketing floods delay OTPs. Naming *priority lanes*, *preference enforcement*, and *idempotency keys* (so a retried request doesn't double-notify) is the senior signal. Good adds channels; great explains why OTP and marketing must never share a queue and how a **fallback chain** (Push fails → SMS) works.

## Trade-offs and failure

- **One service vs per-team**: centralizing gives consistent prefs, throttling, and audit, but becomes a critical dependency — it must be HA, or a login OTP outage blocks the whole company.
- **Real-time vs cost**: SMS is expensive and slow; prefer Push/In-App and fall back to SMS only for high-value types.
- **Failure**: a provider outage triggers the fallback chain, not a hard fail. **Dedup keys** prevent a queue redelivery from sending an OTP twice. Track per-type delivery SLOs — a delayed marketing email is fine, a delayed OTP is an incident.

Architecture

Components and flow

Interview perspective

Trade-offs and failure

Related questions