System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• The system will expose an api for notifications to be scheduled.
  • These can be called by recommendation service and is out of scope. The system will not be responsible for triggering the notification.
• The system will send notification to specified user, devices and scheduled time.
• Users can elect to receive certain type of notifications via certain methods, or opt out receiving notifications.
• The system can rate limit the amount of notifications a user can receive based on settings configured interval and threshold.

Non-Functional:

List non-functional requirements for the system...

• If possible, notification will be sent within 1 minute from scheduled delivery time.
• The notification will be sent to user within 1 minute if device is online; or within minute from the moment the device is back online.
• 34 qps of notification.

Capacity estimation

Estimate the scale of the system you are going to design...

Assume the message needs to be stored for 1 week.

3M notifications per day.

Maximum message size is 10kb.

The total storage size will be 210Gb.

API design

Define what APIs are expected from the system...

• ScheduleNotification
  • input parameters:
    • message: bytes
    • userId: string
    • messageType: int
    • dueTimeStamp: int

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Device Table (relational db)

user id: string

device type: integer

device id: string

delivery info: json blob (fields specific to the device type used for delivery)

last online time: integers

Notification Table (message queue)

message id: string

user id: string

message type: integer

message: string

deliveryTime: integer

User Setting Table

user id: string

message type: integer

opt int: bool

device types: list of integer - if empty, all device should be notified

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

To avoid harassing users with notifications, we'll drop some notifications based on rate limiter. This means that users will miss some notifications.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

• For performance, we'll use at-least-once delivery semantic in message queue. This means users will get duplicate notifications.
• Users may miss notifications, if they change contact info after the notification is scheduled.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

• To mitigate duplicate notification, we can have a cache of unique notifications installed on both scheduler side and notification sender side.
• To make sure newly added contact can get all notifications, when a new contact is added, we can have a backend task to specifically write a message to its device queue.