Notification system

01 · CONTEXT

What a notification platform needs to do

A notification platform receives a message and a recipient from other services and handles delivery by push, email or SMS. Besides sending, it has to respect what the user wants to receive: channel preference (opt-out) and quiet hours are part of the problem, not decoration. In an interview, the first step is gathering requirements: which channels, immediate or scheduled sending, individual sending or a campaign to a segment, and what is out of scope.

The real challenge is not the average but the peak. A campaign that needs to reach many people within a few minutes requires throughput far above the day's average: the case source calculates that delivering one million in five minutes is already over three thousand per second, and proposes sizing the system for surges of five thousand per second. This gap between average and peak is what justifies putting queues in the middle.

02 · ARCHITECTURE

Per-channel queues and workers

The basic design separates whoever requests the notification from whoever delivers it. The notification service validates the request, checks the user's preferences and puts an event on a message queue. Workers pull the events from the queue and send them to the corresponding external service (push, SMS or email). The queue works as a buffer when notification volume is high, and so the peak does not take down delivery.

Using one queue per channel is an isolation choice: if the SMS provider gets slow, only the SMS queue builds up, and push and email keep flowing. Each channel also scales its workers independently, since each provider has its own pace and its own limits.

1. A source service asks the notification service to send; it is the platform's single entry point.

2. Before enqueueing, the service checks the preferences: a channel in opt-out or a quiet-hours window causes the request to be dropped or deferred.

3. The event goes to its channel's queue. The queues absorb the peak and isolate one channel from the others.

4. Each channel's workers pull events from their queue at the pace the provider can handle.

5. The workers call the external providers, which make the final delivery to the user's device, number or mailbox.

03 · RELIABILITY

Retries, failure queue and duplicates

External providers fail, and the platform needs to retry instead of losing the notification. Messages that exhaust their retries go to a dead-letter queue (DLQ), and the Amazon SQS documentation describes its usefulness: isolating unconsumed messages to investigate why processing failed. This way the failure becomes observable data, and the message can be re-examined later, instead of vanishing.

Retries have a side effect: duplicates. The SQS documentation itself warns that standard queues guarantee at-least-once delivery, and that more than one copy of a message may be delivered. That is why the interview asks how to avoid duplicates on top of at-least-once delivery. The practical answer is idempotency: each notification carries an event identifier, and the worker checks whether that identifier has already been processed before sending.

1. The worker receives the event from the channel's queue.

2. Before sending, it checks the event identifier in the log of already-handled events; if it is already there, the notification is not resent.

3. The external provider becomes unavailable: the worker's call fails and the notification has not yet been delivered.

4. The event is delivered again by the queue and the worker tries again; this is where the duplicate check matters.

5. Once retries are exhausted, the event goes to the dead-letter queue, where it can be investigated, and monitoring is alerted.

04 · PRIORITY AND LIMITS

Priority, frequency and single points of failure

Not every notification is worth the same. A verification code cannot wait behind a marketing campaign. The case source raises this as a deep-dive question: how to deliver high-priority notifications within a few seconds even during a mass campaign. One answer consistent with the design is to separate the high-priority queue from the campaign queue, so that the volume of one does not block the other.

Two more precautions complete the design. The first is to limit the frequency of notifications sent to each user, so they are not flooded; the same reasoning as a rate limiter applies here. The second is to avoid single points of failure: the study notes warn that a single notification server can take down the entire system, and so the entry service needs several instances behind a load balancer.

05 · AVAILABILITY

Do not lose what was accepted

The case source highlights a question that sums up the system's promise: how to guarantee that an accepted notification is never dropped. The answer involves durably writing the request before confirming to the caller, and treating delivery as complete only when the provider responds. This ties the case to availability patterns: redundancy in the entry service, replicated queues and stateless workers that can be replaced.