Functional Requirements#

Who is the Client?#

Before listing what the system does, it's worth being precise about who is calling it. This is an internal notification infrastructure — your own backend services (the Instagram "likes" service, the Uber "trip completed" service, the bank "fraud detected" service) call your notification system when something happens. You are not building a third-party platform like Twilio or SendGrid. This distinction matters because it removes concerns like multi-tenant billing, API key management per business, and SLA contracts — and lets you focus purely on reliable, high-scale delivery.

Core Functional Requirements#

1. Multi-channel delivery — push, SMS, and email

The system must deliver notifications across three distinct channels: push notifications (mobile and desktop), SMS, and email. These are not interchangeable — they use completely different delivery infrastructure. Push goes through Apple APNs or Google FCM. SMS goes through telecom carriers (via a provider like Twilio). Email goes through an SMTP-based provider (like SendGrid). The system's job is to be a unified infrastructure on top of all three — the calling service says "notify this user" and the system figures out how to reach them.

2. User channel preferences

Not every notification should be sent on every channel. Users configure which channels they want for which notification types. Someone might want fraud alerts via SMS only, marketing emails turned off entirely, and like-notifications as push only. The system must respect these preferences before dispatching anything — filtering happens before fan-out, not after.

3. Notification content customization

The calling service provides the content — title, body, deep link, image, CTA button. The notification system renders this into the format each channel requires (APNs payload for iOS push, HTML for email, plain text for SMS). The caller owns the template; the system owns the delivery.

4. Scheduled notifications

A caller should be able to say "send this at 9am tomorrow" rather than "send this now." The system must support delayed/scheduled dispatch — storing the notification and firing it at the right time.

5. Delivery status tracking

The calling service needs to know what happened: was the notification sent? Did it reach the device? The system must track delivery status per notification — sent, delivered, failed — and expose this so callers can query it.

6. Click / engagement tracking

Beyond delivery, the caller wants to know if the user actually interacted — did they open the notification, click the CTA? This is engagement tracking, and it's a separate signal from delivery status.

What You Might Miss in an Interview#

At-least-once delivery — a notification must never silently disappear. If push fails because the phone is offline, the system must retry. If SMS fails, it must retry with backoff. Silent drops are unacceptable — especially for transactional notifications (OTP, fraud alert). The system guarantees at-least-once delivery per channel.

Fan-out — one event can trigger notifications to millions of users simultaneously. A celebrity posts on Instagram, and 10 million followers need a push notification in under a minute. This is not a simple one-to-one send — the system must be designed to fan out a single trigger event to a massive recipient list without falling over.

What Is Out of Scope#

• Third-party billing or per-tenant API key management — this is internal infrastructure
• Building APNs, FCM, or SMS carrier infrastructure — we use these as external providers
• Email rendering / HTML design — the caller provides content, we deliver it