Scalable Notification System – System Design Interview Preparation

Practice designing a scalable notification system. Cover push notifications, email, SMS, rate limiting, and delivery guarantees.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Notification System design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Notification System is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Multi-channel delivery with retry, deduplication and preference enforcement - and deciding what "delivered" means when a channel cannot tell you.

Scale to establish before drawing anything

Tens of millions of notifications a day with sharp campaign spikes.
Each channel has different latency, cost and failure behaviour - push is cheap and lossy, SMS costs money per send.
Preference checks happen on every notification, so they are cache-first.

Core components

Notification API – Accepts a request and returns immediately. Nothing is sent in the caller's request path.
Queue – Priority-aware, decoupling producers from per-channel throughput.
Channel workers – One pool per channel, scaled and rate-limited independently against each provider.
Template service – One message rendered per channel, respecting each channel's limits.
Preference service – Opt-ins, quiet hours and frequency caps, checked before send.
Delivery tracker – Status per notification, with provider callbacks reconciled in.

Trade-offs to defend

At-least-once plus deduplication – A timeout leaves delivery unknown. Retrying risks a duplicate and not retrying risks a miss; a dedup key makes the first option safe.
Per-channel retry policy – Push failures are often permanent; SMS failures are often transient. One retry policy for all channels is wrong in both directions.
Campaign spikes – A 10M-user campaign must not delay a password reset. That is a priority queue, not a bigger worker pool.

Follow-up questions to expect

A provider accepts a message and never confirms delivery. What is the final status?
Quiet hours begin while 2M notifications are queued. Dropped, deferred, or sent?
A bug queues the same notification five times. What in your design limits the damage?