Introduction to Notification Systems

Most tutorials describe notifications as "send an email when something happens." That is technically true, but it is not how production systems are designed. A real notification platform decides what happened, who should know, which channel should be used, whether the user allowed that channel, how fast it must arrive, and what to do when the provider fails.

Netflix uses notifications to bring you back when a new episode is available. Swiggy uses them to reduce anxiety during an order. Amazon uses them to coordinate payment, warehouse, courier, and customer updates. GitHub uses them to keep collaboration moving. Google uses them to warn you when a suspicious login appears. The same word, notification, covers different urgency, cost, and risk levels.

Communication vs Notification

Communication is broad. A support email, a newsletter, and a sales call are communication. A notification is event-driven and context-specific. It exists because something happened or is about to happen.

Examples:

Netflix: New Episode Available
Swiggy: Your order is being prepared
Amazon: Package out for delivery
GitHub: Someone mentioned you in an issue
Google: Suspicious login detected

The Netflix message can wait a few minutes. The Google security alert should not. A Swiggy order update should be fast because the user is actively waiting. A GitHub mention can be in-app first and email later if unread. These trade-offs drive the architecture.

Notification Channels

Channel   Speed     Cost       Best For                     Common Risk
Email     Slow      Cheap      invoices, reports, marketing spam folder
SMS       Fast      Expensive  OTP, fraud alerts            cost abuse
Push      Instant   Cheap      mobile activity              token expiry
In-app    Instant   Cheap      dashboard updates            unseen if offline

Email is good when the content is long, durable, or needs attachments. SMS is good when the user must act quickly and may not have internet. Push is best when the app is installed and the message should feel immediate. In-app notification is best for product activity because it keeps context inside the product.

User Journey

Customer
  |
  v
Places Order
  |
  v
Backend receives event
  |
  v
Notification generated
  |
  v
Worker processes
  |
  +--> SMS sent
  +--> Push sent
  +--> Email sent

The customer is not thinking about queues or workers. They want confidence that the order moved forward. The backend receives the order event but should not spend three seconds calling every provider. The notification system turns the event into channel-specific jobs. Workers process those jobs independently and update delivery status.

Base Architecture

                 Notification System

                   +-----------+
                   | Backend   |
                   +-----------+
                         |
                         v
              +--------------------+
              | Notification API   |
              +--------------------+
                         |
          +--------------+-------------+
          |                            |
          v                            v
      Database                      Queue
          |                            |
          +------------+---------------+
                       |
                       v
                 Worker Service
                       |
        +--------------+---------------+
        |              |               |
        v              v               v
      Email           SMS             Push

The backend publishes intent: "OrderPlaced happened for user 123." The Notification API validates the request, stores a notification record, resolves preferences, and enqueues work. The database is the source of truth. The queue is the work buffer. The worker service performs slow provider calls outside the user-facing request path.

Implementation Sketch

type NotificationRequest = {
  event: "ORDER_PLACED" | "PAYMENT_SUCCESS" | "PASSWORD_CHANGED";
  userId: string;
  channels: Array<"email" | "sms" | "push" | "in_app">;
  variables: Record<string, string>;
};

async function createNotification(request: NotificationRequest) {
  const notification = await db.notification.create({
    data: {
      event: request.event,
      userId: request.userId,
      status: "queued",
      variables: request.variables
    }
  });

  await queue.add("send-notification", {
    notificationId: notification.id,
    channels: request.channels
  });

  return notification;
}

Notice what this code does not do: it does not call SendGrid, Twilio, FCM, or APNS inside the product request. That is the first production boundary.

Common Mistakes

1. Sending provider calls directly from the checkout request.
2. Treating all notifications as equally urgent.
3. Not storing delivery status.
4. Ignoring user preferences.
5. Having no retry or dead-letter strategy.

Interview Questions

1. Why should notification delivery be asynchronous?
2. When would SMS be better than push?
3. Why does the database still matter if you already have a queue?
4. What can go wrong if notifications are sent inside the main backend request?

Exercise

Pick an app you use every day. List five notifications it sends, classify each by channel, and write down why that channel is appropriate.