Design a Notification System/Playground
Notifications across email, push and in-app
Click a part to change it, put something in front of it, or kill it. Turn the traffic up. Every number moves as you go; nothing is graded. 2 million events a day become about 8 million notifications, with work-hour peaks near 10×; the email provider takes 500 a second.
- Requests failing
- 0%
- Backlog growing
- none
- Instances running
- 308
What goes through it
| Operation | Offered | Outcome | Wait | Up |
|---|---|---|---|---|
| Product events | 230/s | All served | 3 ms | 99.990% |
| Emailsbackground | 370/s | Keeping up | – | – |
| Push notificationsbackground | 560/s | Keeping up | – | – |
| Inbox reads | 2,000/s | All served | 35 ms | 99.95% |
Wait is the expected time a caller waits; Up is the share of time every part it waits on is running.
What your changes did
Nothing yet. This is the reference design: change something to see what it buys and costs.
At this traffic
Risk:
Product events stop if its one instance does. Kill it to see.
ReplicationMux: What we learned from a 22-Day storage bug (and how we fixed it) ↗
Risk:
Product events and Inbox reads stop if its one instance does. Kill it to see.
ReplicationMux: What we learned from a 22-Day storage bug (and how we fixed it) ↗
Ask AI what your design does
AIThe numbers above come from a simple model. The AI reads your design, what you changed and these numbers, and explains where it holds and where it fails, citing how the engineers who built it did it. It can be wrong.