Requirements

Functional Requirements:

• Send targeted notifications based on user attributes, device, and preferences.
• Schedule notification delivery for immediate or delayed send.
• Deliver notifications across multiple platforms including iOS (APNS), Android (FCM), and web browsers (Web Push).
• Track user engagement with notifications including clicks, dismissals, and opens.
• Manage user opt-in/opt-out preferences and notification settings.

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
• Low Latency :- Low latency means here we were minimizing the response time , to maintain that we will be adding async processing and cache. (this will make our system faster)
• Scalability:- Our system should be scalable in the sense, when we were in peak time it should handle that increase amount of load by doing scaling out (Horizontal Scaling) and scale up(Vertical Scaling). it should handle this using automatically like with the help of HPA(Horizontal Pod AutoScaler). It ensure by adding resources at peak time and remove at idle time automatically.
• Reliability :- The system should be have as it it what it intend to behave that is what our reliability refers, in this case it make sure by using Fault Tolerance (Resilience4j / Fall back mechanism) , Load balancer (which distribute the load traffic requests), Redundancy ( Remove duplicate critical components so the system keep running)

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

our api should be like this :-

• (POST API) v1/deviceRegistration/addDevice (for all 3 type of device resgistration and stored in DB)
• (POST API) v1/notification/send (send to a device)
• (POST API) v1/notification/bulk/send - public string sendBulkNotification(List<Device> bulkDevice) (send notification to bulk devices)
• (POST API) v1/device/deviceSettings (opt-in/opt-out)

payload :-

{

"user_id": "user-789",

"preferences": [

{ "category": "marketing", "enabled": false },

{ "category": "transactional", "enabled": true },

{ "category": "reminders", "enabled": true }

],

"quiet_hours": { "start": "22:00", "end": "08:00" }

}

• (POST API) v1/analysis/trackUser (track user clicks or user notifications)

Here we will track user action using below paramters - userId, deviceId, action, timeStamp.

json payload will be :-

{

"notification_id": "uuid-12345",

"user_id": "user-789",

"device_id": "device-xyz",

"action": "CLICKED", // Options: DELIVERED, CLICKED, DISMISSED

"timestamp": "2026-05-05T11:42:12Z",

"metadata": {

"platform": "ios",

"campaign_id": "summer_sale_2026"

}

}

• (POST API) v1/notification/status

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Our components will be :-

1. Services
2. A server
3. Database
4. Message Queue
5. Workers
6. Third Party Services
7. Devices
8. Redis Cache
9. DLQ (Dead letter Queue)

Will go in detail design :-

1. Services to register user device
2. A server who will take user details from services and process for storing it.
3. Database for user device details will be stored with a link to user id (which user has which device.)
4. Message Queue to send that message or notification.
5. Workers will be there to pull all the message and notification from message queue and process it.
6. Third party services is used for talking to different different devices like APNs for IOS , FCM for android device, Web push will be for Web.
7. And devices will be for who will receive the message or notification.

• The Fan-out Patterns : The Fan out pattern explain that when a "Marketing campaign" starts, the API doesnt send 1 million notifications. It creates one "Campaign Job." The Workers then fetch the list of 1 million target user_ids, look up their device_tokens from DB/ Cache, and push individual tasks into the Message Queue.
• Load balancing: Loadbalancing use an API gateway (like Nginx or AWS LB) to distribute incoming traffic across multiple instances of your Notification server to ensure High Availability.
• Microservice Vs Monolith: State that the scheduler, worker and tracking service are independent microservices. if the "Tracking Service" slows down, it wont stop notifications from being sent.

Scheduler Prioritization:-

Not all notifications are equal. A "security alert" (OTP) is more important than a "20% off coupon". we should implement priority queuing.

• Logic - Use multiple queues(ex:- High, Medium, Low) or a priority Attribute within our message queue(like kafka or rabbitmq)
• The tiers:

High Priority: Transactional alerts(OTP, Payment success). These bypass the main queue and are processed by dedicated "express workers"

Medium Priority: Time-sensitive alerts (Friend requests, messaging).

Low Priority: Marketing campaigns and newsletters. these are processed only where the high / meidum queues are near empty.

Weight Fair Queuing: workers are allocated in ratio(ex:- 70% of workers listen to hight priority queue, 30% to Low-priority) to ensure low-priority tasks never completely "starve"

Tracking Service(User action) :-

The tracking service provides a public endpoint (ex- POST /v1/track) that the mobile app calls when a notification is clicked. It captured click_event, delivery_receipt, dismisal_event. why it is separated ? By making this separate service, we ensure that a massive surge in clicks(ex- during a breaking news alert) doesnt slow down sending workers.

Database Schema:

Since we were using a Relational DB we have table like this

• Users: user_id, email, created_at
• Device_tokens: user_id, token_id, platform_type, is_active.
• Notification_History: notification_id, user_id, status (sent/delivered/clicked), created_at.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Our components will be :-

1. Services
2. A server
3. Database
4. Message Queue
5. Worker
6. Third Party Services
7. Devices
8. Redis Cache
9. DLQ (Dead letter Queue)

Will go in detail design :-

1. Services to register user device
2. A server who will take user details from services and process for storing it.
3. Database for user device details will be stored with a link to user id (which user has which device.)
4. Message Queue to send that message or notification.
5. Workers will be there to pull all the message and notification from message queue and process it.
6. Third party services is used for talking to different different devices like APNs for IOS , FCM for android device, Web push will be for Web.
7. And devices will be for who will receive the message or notification.

The Message Queue (Reliability) :-

• Partitioning :- Use a partitioned queue (like kafka) keyed by user_id. This ensures that notifications for a single user are processed in the order they were sent.
• Dead Letter Queue (DLQ): if a notifications fails 3 times (e.g - due to a network glitch), move it to DLQ for manual inspection instead of clogging the main queue.

The Redis Cache(Peformance)

• Write-Through Cache: When a user update their notification settings, update the DB first, then the cache.
• TTL (Time to Live): set a TTL for device tokens, if a user hasnt opened the app in 30 days, remove them from the cache to save memory.

The Workers (The Executioners)

• Rate Limiting: Third party providers (APNS/FCM) have limits. Your workers must implement Throttling to ensure you dont get banned for sending too many requests at once.
• Statelessness: workers should be stateless. if one worker crashes, another should be pick up the task from the queue immediately.

Database Schema:

Since we were using a Relational DB we have table like this

• Users: user_id, email, created_at
• Device_tokens: user_id, token_id, platform_type, is_active.
• Notification_History: notification_id, user_id, status (sent/delivered/clicked), created_at.

Asynchronous Engagement Processing :-

The tracking API is a "fire and forget" entry point to ensure the users app feels fast.

The Ingestion Flow : when a user clicks a notification, the app sends a request to the Tracking Service. This service does not write directly to the main db.

The Buffer: The tracking service acts as a producer for a dedicated analytics topic. This decouples the "recording" of the event from the "processing". why this matters :-if a breaking news alert causes 10 million clicks in 60 seconds, our DB wont lockup beacuse of kafka "buffers" the load.