Home / Blog / System Design Notification Service Interview Guide

System Design Notification Service Interview Guide

Published 2026-10-09 · Luna Interview

A system design notification service interview asks you to deliver messages across email, push, SMS, and in-app channels without melting providers or spamming users. Candidates commonly report this prompt when teams own growth, marketplace, or platform messaging. This guide gives you a talk track for requirements, fan-out, queues, templates, and delivery tradeoffs.

Start with the product job

Notifications are not “send email.” They are timely, preference-aware, multi-channel delivery with auditability.

Clarify:

• Channels: email, mobile push, SMS, in-app, webhook?
• Triggers: user actions, cron digests, system alerts?
• Priority: transactional (receipt, 2FA) vs marketing?
• Delivery semantics: at-least-once OK? exactly-once illusion via idempotency?
• User preferences and quiet hours?
• Volume: messages/day, peak fan-out (one event → millions)?
• Latency: 2FA in seconds vs digest in hours?

Talk track:

“I’ll separate transactional from marketing, support email + push first, honor preferences and quiet hours, and aim for at-least-once delivery with idempotent providers and dedupe keys.”

High-level shape

1. Producer API — services enqueue a notification intent
2. Orchestrator — resolve recipients, templates, channel preference
3. Per-channel workers — talk to SES/SendGrid, APNs/FCM, Twilio, etc.
4. Preference & template stores
5. Status / outbox — delivered, failed, opened (where available)

Draw producers → queue → orchestrator → channel queues → providers. Keep the first diagram readable.

API sketch

• POST /v1/notifications { templateId, userId | segment, data, priority, channels? }
• POST /v1/events (optional) { eventType, actorId, payload } → rules expand to notifications
• GET /v1/notifications/{id} status
• User prefs: GET/PUT /v1/users/{id}/preferences

Idempotency key on create so retries do not double-send.

Fan-out patterns

Talk track:

“For a single-user receipt I’ll expand inline. For a broadcast I’ll enqueue an expansion job that pages recipients and publishes per-user channel jobs so we do not block the producer.”

Queues and backpressure

• One ingress topic for intents
• Separate channel queues so SMS slowness does not block email
• Priority queues or separate lanes for OTP vs newsletter
• Rate limiters per provider account and per user

When a provider throttles, retry with exponential backoff + jitter; dead-letter after N tries with alerting.

Templates and rendering

• Store templates by templateId + locale
• Render with strict allowlists (no arbitrary HTML from users)
• Keep PII out of logs; template data may be sensitive

Talk track:

“Orchestrator loads template + user locale, renders channel-specific payloads, then enqueues channel jobs with a dedupe key of notificationId+channel.”

Preferences, quiet hours, frequency caps

Before send:

1. User opted into this category?
2. Channel enabled?
3. Quiet hours? (delay or skip non-transactional)
4. Frequency cap for marketing?

Transactional usually bypasses marketing caps but still respects legal opt-outs where required. Say you will confirm product/legal constraints rather than inventing policy.

Delivery guarantees (be honest)

True exactly-once across SMS/email is unrealistic. Aim for:

• At-least-once processing
• Idempotent provider calls (idempotency keys)
• Dedupe window on (user, template, businessKey)

Talk track:

“I’ll promise at-least-once with idempotency keys so users do not get three OTPs from the same intent. Exactly-once end-to-end is not something I’d claim.”

Capacity sketch

Example assumptions (adjust live):

• 50M notifications/day ≈ ~600/sec average, peak 5–10×
• Email 70%, push 25%, SMS 5% (SMS expensive—call it out)
• Fan-out event: 1 producer message → 100k channel jobs over minutes

Size workers from peak channel QPS and provider rate limits, not from average.

Data stores

• Preferences: user-keyed, strongly read for orchestrator
• Templates: versioned documents
• Notification log: append-oriented (who got what, status)
• Optional outbox table in producer DB for reliable enqueue

Do not put the entire send history in the OLTP path of the producer service.

Observability and abuse

Must mention:

• Metrics: enqueue rate, render latency, provider errors, DLQ depth
• Tracing across intent → channel → provider response
• Bounce/complaint handling for email reputation
• Opt-out webhooks
• Authz on producer API (services, not random clients)

Failure modes worth naming

• Provider outage → buffer and retry; status “deferred”
• Bad template → fail closed for that intent; alert
• Preference store down → fail safe for marketing; careful policy for OTP (cached prefs?)
• Hot key user (too many notifies) → per-user rate limit

First ten minutes

1. Channels + transactional vs marketing (2 min)
2. API + idempotency (1 min)
3. Architecture diagram with queues (3 min)
4. Preferences / quiet hours (1 min)
5. Guarantees + retries/DLQ (2 min)
6. Scale fan-out if prompted (1 min)

Tradeoffs table

Soft practice note

Notification designs are preference logic plus queue discipline. If you want a Chrome side panel to rehearse this system design notification service talk track under timed pressure, Luna Interview is built for calm rehearsal. Use it to build structured tradeoff talk—not to fake provider outages or to violate interview rules.

Day-of checklist

• [ ] Channels and priority classes named
• [ ] Producer API with idempotency key
• [ ] Orchestrator vs channel workers separated
• [ ] Preferences + quiet hours in the path
• [ ] At-least-once + dedupe stated honestly
• [ ] Backpressure / DLQ mentioned
• [ ] Fan-out strategy for large audiences
• [ ] Metrics and bounce handling noted

Deliver intents through queues; respect prefs; never claim magic exactly-once—that is the notification service interview guide.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.