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. Worker
6. Third Party Services
7. Devices

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.

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

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.