Notification System – Low Level Design Interview Practice
Practise the Notification System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Asynchrony and delivery guarantees. Anyone can model Email, SMS and Push; the round is about queueing, retry, and what "sent" actually means.
Requirements to establish first
- Send a notification over several channels, chosen per user preference.
- Template a message once and render it per channel with its own limits.
- Queue sends rather than blocking the caller.
- Retry failures with backoff, and stop after a bounded number of attempts.
- Respect user preferences, quiet hours and unsubscribes.
Core classes
- Notification – Recipient, template, data, priority. Channel-agnostic.
- NotificationChannel – Email, SMS, push, in-app - each with its own send and its own failure modes.
- Template / Renderer – One message, rendered per channel. An SMS truncates where an email does not.
- NotificationQueue – Decouples the caller from the send. Priority-aware if urgent notifications exist.
- RetryPolicy – Attempt count and backoff, which differ by channel.
- UserPreference – Channel opt-ins, quiet hours, rate caps.
Design patterns that apply
- Strategy – Channel selection and retry policy, which vary independently.
- Observer – Domain events raise notifications without the domain knowing a notification system exists.
- Factory – Channel instantiation from a preference, so adding WhatsApp is a registration.
- Decorator – Cross-cutting concerns on a send - rate limiting, deduplication, logging - stacked without touching the channel.
Follow-up questions to expect
- A send times out and you cannot tell whether it arrived. Retry and risk a duplicate, or drop and risk a miss? Say which this system chooses and why.
- Quiet hours start while a notification is queued. Is it dropped, deferred, or sent?
- One channel is down. Does the user get nothing, or does your design fall back - and does the user want that?
Where candidates lose marks
- Sending synchronously in the request path, which couples a checkout to an SMS gateway.
- One retry policy for every channel, when push and email fail very differently.
- No deduplication, so a retry after an ambiguous timeout sends twice.