Notification System System Design Interview: Walkthrough

A notification system system design interview looks easy because everyone has received a push, an email or a text. That familiarity is exactly why interviewers use it. They are not testing whether you know a diagram. They are watching how you turn a vague prompt into a sequence of decisions you can defend: clarify requirements, estimate volume, sketch a first design, work through channel fan-out and delivery guarantees, then name the trade-offs and bottlenecks. This walkthrough narrates that sequence out loud, in the order you would actually speak it.

It is written for mid-level and senior engineers, including people returning to interview loops after a break. The goal is a repeatable habit of reasoning aloud, not a memorised architecture — by the end you will be able to run the whole sequence from requirements to wrap-up without notes.

What the Notification System System Design Interview Is Really Scoring

Use the four criteria below to order your answer: requirements first, boundaries second, failure handling third, trade-offs throughout.

Requirement gathering. Do you narrow an unbounded problem before drawing boxes?
Component boundaries. Can you name what each service owns and what it does not?
Failure handling. What happens when a provider is slow, a queue backs up, or a message is delivered twice?
Trade-off reasoning. When you choose something, can you say what you gave up?

Set expectations at the start. Say something like: "I'll clarify requirements, do a rough estimate, sketch a first design, then spend more time on fan-out and delivery guarantees, and finish with trade-offs and bottlenecks." That sentence buys you a structure the interviewer can follow, and it signals that you know where you are going.

Step 1: Clarify Requirements Before You Draw Anything

Ask who sends and who receives. Senders might be internal services reacting to product events, a marketing tool, or an operations dashboard. Receivers might be end users on devices, inboxes, or an in-app feed. Those answers change the design more than any technology choice.

Then split functional from non-functional requirements. Functional requirements are the verbs: accept a notification request, validate it, route it to a channel, deliver it, track its status, and respect user preferences. Non-functional requirements are the constraints: scale, latency targets for urgent messages, delivery guarantees, ordering, deduplication and cost per send. If you want to rehearse that split on its own, our article on non-functional requirements takes the same requirement-first discipline into a different case.

Name the non-functional ones explicitly rather than letting them surface later. State each as an assumption you can be challenged on: "Urgent security alerts should reach the device within seconds, so I'll treat latency as a hard constraint for that class of message and a soft one for marketing."

State assumptions out loud and write them down. "I'll assume ten million notifications a day, at-least-once delivery, and no strict ordering except for security alerts." A stated assumption is a decision the interviewer can challenge, and a challenge is a conversation — which is what you want.

Step 2: Back-of-the-Envelope Numbers That Shape the Design

Keep the arithmetic simple, and say why each number matters. The estimate is an argument, not a quiz answer. The figures below are illustrative — pick your own and justify them.

Here is an example of how that transition can sound out loud:

"So my assumptions are ten million notifications a day, at-least-once delivery, and no strict ordering except for security alerts. Let me turn that into a rate. Ten million a day is roughly a hundred and twenty a second on average, but sends cluster around campaigns, so I'll plan for a peak multiplier of ten — about twelve hundred a second. That tells me acceptance can stay synchronous, because it's a small write, but delivery has to be asynchronous. And if one product event fans out to a million devices, that single event is a burst my workers must absorb without stalling everything else."

Two more numbers are worth a sentence each. Payload: estimate the size of a notification record with its metadata, and note that the rendered message adds more, which justifies storing records separately from templates. Retention: decide how long delivery history lives, because it drives storage cost and how you query status.

Step 3: A First-Pass Notification System Architecture

Walk the request path in order, and keep the first diagram deliberately small.

API gateway. Authenticates the caller, applies rate limits, forwards the request.
Notification service. Validates the request, checks user preferences and quiet hours, resolves the template, and writes a notification record.
Queue. Sits between acceptance and delivery.
Channel workers. One pool per channel, each pulling from its queue.
Provider adapters. Thin clients for push, email, SMS and in-app providers.

The queue earns its place for three reasons: it decouples acceptance from delivery, it buffers spikes so a marketing blast does not stall security alerts, and it isolates retries so a failing provider does not block the rest.

At a high level, the data model has four parts: the notification record, a per-channel delivery attempt with its status, user preferences, and templates. Say that out loud, then stop. Complexity should be added only when a requirement forces it. If you want to see the same first-pass discipline applied to a smaller problem, the rate limiter walkthrough follows a similar shape of reasoning out loud before committing to detail.

Step 4: Channel Fan-Out and Provider Integration

Treat push, email, SMS and in-app as separate channels behind a common interface. Each gets its own worker pool and its own rate limits, because their constraints differ sharply.

Narrate the split rather than listing it. Something like: "I'm putting each channel behind the same interface, but giving each its own worker pool and rate limit, because email and SMS depend on third parties with their own throughput caps. If I share one pool, a slow email provider starves push."

Third-party providers bring their own rules. Throughput caps mean you cannot drain a queue as fast as you can fill it. Retry semantics vary: some providers accept a message and report delivery later, others fail fast. Delivery receipts arrive asynchronously and must be reconciled against your records. And most third-party sends carry a per-message cost, which is a design input, not an afterthought.

Idempotency keys are how you avoid sending the same message twice when a job is retried. Generate the key when the notification is created, carry it through the queue, and let the provider adapter drop duplicates it has already seen. Say it plainly: "The key is created once, at acceptance, and travels with the job. The adapter is the last line of defence."

Templating and localisation belong behind a service boundary rather than scattered across workers. One place resolves a template into a rendered message; workers just deliver what they are given.

Step 5: Reliability, Ordering and Deduplication

Name the guarantee you are choosing before you describe the machinery.

Delivery guarantees. At-most-once never duplicates but can drop messages; at-least-once can duplicate but does not drop. Many notification systems choose at-least-once plus deduplication, and accept the extra bookkeeping.
Retries. Exponential backoff with jitter avoids a thundering herd when a provider recovers. After a bounded number of attempts, move the message to a dead-letter queue for inspection.
Ordering. Ordering usually matters only within a channel and per recipient, so serialise messages for one recipient rather than globally. Say which one you need.
Preferences and quiet hours. These are a first-class check at acceptance time, not a filter bolted onto a worker.

A short script for the deduplication question: "I'd keep a dedupe key per notification and per channel, stored with a time-to-live. A retried job checks the key before calling the provider. That gives me at-least-once delivery without spamming the user."

Step 6: Trade-Offs to Say Out Loud

Frame each trade-off as a choice with a cost, and say the cost out loud.

Push versus pull for devices. Push gives lower latency but costs battery and requires provider infrastructure. Pull is simpler to operate and slower to notify. "I'd choose push for time-sensitive alerts and accept the battery cost."
One queue per channel versus a shared queue. Per-channel queues isolate blast radius — a stuck email provider does not delay pushes — at the cost of more operational surface. "I'd start shared for simplicity and split when a channel's failure starts hurting the others."
Strong versus eventual consistency on delivery status. Strong consistency makes status reads expensive; eventual consistency is cheaper and usually good enough, since a status page can lag by seconds. "I'd take eventual consistency here and say so, because in most cases nobody is blocked on a delivery receipt."
Build versus buy per channel. Frame it as cost, control and compliance rather than preference. Email and SMS usually mean buying; in-app often means building.

If you want more practice at this layer, the rate limiter walkthrough shows how to keep constraints and their costs in the same conversation.

Step 7: Bottlenecks, Failure Modes and What You Would Do Next

Name the bottlenecks before the interviewer does.

Hot partitions. One large customer or one viral event can dominate traffic. Mitigations include partitioning by recipient rather than by sender, and smoothing bursts with a queue.

Provider outage. Circuit-break the failing adapter, fall back to another channel where the message allows it, and degrade gracefully rather than retrying into a wall.

Observability. Queue depth, delivery success rate by channel, latency percentiles, and per-channel dashboards. Without these, you cannot tell a slow provider from a slow worker.

Changed requirements. If the interviewer revises a constraint halfway through — say, strict ordering for all messages, or a new channel — restate the new constraint, say which part of the design it invalidates, and adjust only that part. "That changes my ordering assumption, so I'd serialise per recipient and leave the rest of the diagram alone." Naming the impact out loud shows you understand the design rather than reciting it.

Close by naming what you would improve with more time — richer preference modelling, a replay tool for dead-lettered messages, or per-tenant quotas. Saying this signals judgement, not incompleteness. It shows you know where the design is thin, and it is often the part of a notification system system design interview that interviewers remember.

How to Practise This Walkthrough Honestly

Rehearse the sequence out loud: requirements, numbers, first design, the fan-out and delivery section, trade-offs, wrap-up. Time yourself against the slot you are given and notice where you drift into detail too early. A common trap is over-explaining the first diagram and running out of room for the interesting parts, so spend your detail budget on trade-offs instead.

Record yourself and review the structure, not the wording. Ask: did I state assumptions? Did I name a trade-off before being asked? Did I say what I would change? Those three habits usually carry more weight than any specific technology.

Use the same discipline in real interviews. Explain your assumptions, invite the interviewer into the decision, and treat a mid-interview requirement change as a gift — it is a chance to show how you adapt. The database sharding walkthrough is a good second case to run through the same routine.

Before You Walk In

Pick one habit to work on this week: state your assumptions before you draw anything, and say out loud what each number changes. Run the walkthrough once with a timer, then once more without notes, and notice which step you rush.

Frequently asked questions

How long should a notification system system design interview answer take?

It depends on the slot you are given, so ask or infer it early. If you have roughly 35 to 45 minutes, a workable split I'd suggest is about five minutes on requirements, five on estimates, ten on the first-pass design, ten to fifteen on the fan-out and delivery guarantees section, and the rest on trade-offs, bottlenecks and wrap-up. Treat that as a starting point, not a rule.

Should I design one notification service or separate services per channel?

Whichever you pick, say what it costs you. A single service is easier to operate and reason about early on; per-channel services limit the blast radius of one provider's outage but multiply deployments, dashboards and on-call surface. Naming that cost is the point of the question.

Do I need to know specific message queue technologies to answer this question?

No. Choose between naming a technology and describing properties by asking what the interviewer needs from you: a product name only helps if you can then say which of its properties you are relying on. If you are unsure, describe the properties — durable storage, at-least-once delivery, dead-letter support — and offer a name as an example rather than a commitment.

How do I handle delivery guarantees without overcomplicating the design?

Write down the smallest set of parts the guarantee needs, then check each one earns its place. A dedupe key with a time-to-live, a bounded retry count and a dead-letter queue cover most answers. If a part does not change what the user experiences, leave it out and say why.

What should I do if the interviewer changes the requirements halfway through?

Ask a clarifying question back before you redraw anything: does the new constraint apply to every message or only some, and does it replace an earlier assumption or add to it? The answer tells you the scope of the change. Phrasing it as a question also keeps the interviewer involved in the decision, which is usually what they want to see.

Is it better to draw the diagram first or gather requirements first?

Gather requirements first. A diagram drawn before you know the scale, latency targets and delivery guarantees is a guess, and interviewers usually score the reasoning that leads to the boxes. Sketch only after you have stated your assumptions.

Practise this walkthrough out loud before your next loop.