Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
Users can opt-out of notifications
Support for multiple devices per user
Support for mobile (android, Apple), SMS, and Email notifications
We'll want some analytics
Support for various notification message templates
List non-functional requirements for the system...
Doesn't have to be hard-real time (some delay is okay)
Save user device data/settings
favor "at least once" delivery
Estimate the scale of the system you are going to design...
10M notifications per day
10M DAU
1 notification per day per user
each users has 2 devices avg
Define what APIs are expected from the system...
POST(template_1, userId, message)
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...
User Table:
Device Table:
userId fk
deviceId id
device_name "apple iphone 14"
opt_out bool
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...
3 main components:
3rd party services:
metadata servers:
notification servers + fanout queues:
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...
Notification is triggered
Sent to our server, where device/user data lookup happens
If not opted out, enqueue a notification message for the user's devices
Update analytics along the way - "delivery pending"
Consumers read from those queue
Update analytics "delivered"
When user clicks on the notification, update analytics
"clicked"
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...
load balancers + stateless APIs
queues - partitioning and replication of the queues to avoid data loss if one goes down.
Explain any trade offs you have made and why you made certain tech choices...
"at least once" delivery - sometimes a notification can be sent twice, in favor of not missing a notification or introducing extra complexity for guaranteeing "exactly once" delivery
Using http2 vs mqtt - http2 is generally more applicable, and favored for the built-in security features. mqtt is better for low-bandwidth devices and high-latency networks.
Try to discuss as many failure scenarios/bottlenecks as possible.
If a notifications fails to be delivered - retry and re-enqueue the message
If a server or message broker goes down - bring it back up
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Build out an MQTT broker, and support MQTT features for better performance