Requirements

Functional Requirements:

• Ability to send notification synchronously
• Ability to target specific cohort of userId and devices
• Ability to schedule notification to be delivered
• Ability to personalize notification based on user information (name, location, etc.)
• Ability to track how many notifications are delivered, to evaluation effectiveness
• Ability to distribute notification sent across a certain period of time to not create a big load of TPS

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• Performance
• Highly scalable
• Reliability should be high > 99%
• Notification delivery rate should be optimized (normally this is around 50% depending on if customer actually have notification enabled)

Traffic TPS:

• Suppose we send notification to 10 million customers everyday, within 8 hours time window when user is using their phone. This creates 350 TPS of traffic

Data Size

• Say we schedule 10 million notification on a daily basis, each record is 10 bytes. This adds up to be 85k GB per year. Although we can add optimization to clean up the records. We should go with a noSQL data base for scaling.

API Design

• sendNotification(userids, deviceIds, text): API to to send notification synchronously,
• scheduleNotification(userids, deviceids, text, time, config): Ability to schedule notification to be delivered. Target specific cohort of userId and devices. The config parameter will direct to configuration that allows personalization.
• setPerosnlizationCoonfigureation (userIds, deviceids, config)
• getDeliverySuccessRate(userIds, deviceids): Ability to track how many notifications are delivered, to evaluation effectiveness

High-Level Design

First there will be a Rate limiter and load balancer in front.

Services

• NotificationService: this is the service responsible for sync operations (sending notification, schedule notification, get success rate, personalization, etc)
• AsyncSchedulingService: async worker responsible to reading the scheduled notification, and call Deliver service to send them
  • Trigger function: step function that gets triggered every time window (5 to 10 mins), get scheduled notification in the next time window, and put them into SQS queue
  • SQS queue: processing queue for notification to be sent
  • NotificationProcesser: Lambda that read from SQS queue, and calls notification services to send the notification

DB

• Schedule DB, responsible to record notifications scheduled
  • schedule id
  • starttime
  • endTime
  • Text
  • Configuration
• Configuration DB, responsible to store configuration based information (customer name, device name, etc) for personalization
  • userId
  • deviceId
  • DeviceName
  • Customer Location
• Tracking DB: responsible for storing deliver success record
  • notificationId
  • success/failure
  • error code
  • error message

Detailed Component Design

• Ability to send notification synchronously:
  • clients can call sendNotification API in notification service to send notification synchronously, targeting specific cohort of userId and devices.
  • notification service will call third party tools (AWS pinpoint) or iOS/Android endpoint to send the notification.
  • Upon sending, there will be an error code coming back, notification service will store notification id and error code in tracking DB.
• AsyncScheduleService will contain the following components
  • Trigger function: step function that gets triggered every time window (5 to 10 mins), get scheduled notification in the next time window, and put them into SQS queue
  • SQS queue: processing queue for notification to be sent
  • NotificationProcesser: Lambda that read from SQS queue, and calls notification services to send the notification
• Personalization: clients call call set configuration to store personalization configuration that will alter be used for different set of notification. When notification specifics a configuration, notification services will call configuration DB to get relevant configuration.
• Ability to track how many notifications are delivered, to evaluation effectiveness: this can be done by calling getDeliverySuccessRate API in notification service, which will call tracking DB.

Scaling bottleneck

• Large amount of notification: it's possible that there's a large amount of notification scheduled that failed to be sent within a certain time window. In this case, we can add functionality to the trigger function to move notification failed to send within a time window to a lower priority queue. When the Notification processor has bandwidth after processing messages from higher priority queue it will go to the lower priority queue.
• Limit: we can also limit the notification scheduling that's higher than capacity and return a 400s.

Edge cases

• Notification are not evenly distributed. when a notification is scheduled among a longer period of time, within the schlepping API we can break time into smaller time windows, so we don't have a large amount of notification send within a short period of time.
• Past notification: past notification are likely not useful. We can create a async clean up function in the shceulder to clean up stale data in schedule DB and tracking DB