Notification System

This is a platform problem rather than a user-facing product. Our customers are other engineering teams. The auth service sends one-time passwords (OTPs, the short-lived login codes users type in at sign-in), the marketing team blasts a promo to a million users at once, and the product team pings you when someone comments on your post. All of that flows through one system, so the design has to carry low-volume, latency-sensitive traffic alongside huge scheduled bursts.

Before writing the non-functional requirements, it's worth pinning down the scale. This is a platform question, so how it holds up under load is most of what we're being asked, and for this system the shape of the traffic matters more than the total. Say we deliver 10M notifications per day. Spread evenly that's only around 100 per second, which is honestly nothing. But notifications don't spread evenly. When marketing schedules a campaign to 1M users at 9am, they want it delivered at 9am, not trickled out over the day. Delivering 1M notifications within 5 minutes is over 3,000 per second, and that's a single campaign. Nothing stops two teams from scheduling their blasts for the same 9am. We'll design for surges of 5,000 notifications per second, roughly 50x our sustained rate, but treat the number as a design point rather than a ceiling. What matters more than the number is how the system behaves past it. An overload should stretch a promo blast from 5 minutes to 8, not break anything, and critical traffic shouldn't feel it at all. We'll hold ourselves to that in the deep dives.