Design a Notification System

A Snapstreak shows an hourglass when two friends are closing in on 24 hours without trading a Snap, and that hourglass rides in on a push notification fired at a precise moment. Hold that image, because it tells you this prompt is two systems wearing one name. Most of the volume is real-time: a friend sent you a Snap, posted to their Story, replied in chat, or showed up on the Map. Those are events that already happened and need to reach one or a few people fast. The streak reminder is the opposite shape. Nothing happened. The system has to notice that something is about to stop happening and fire ahead of a deadline.

Name that split first and the design organizes itself. One path is event-driven and reactive, triggered by a Snap leaving a sender's phone. The other is timer-driven and predictive, triggered by a clock reaching a streak's warning window. They share a back half, the part that coalesces, rate-limits, and delivers, but the front halves have nothing in common. Spend the hour on the streak scheduler and the real-time fan-out, because those are the two halves with a Snap-shaped answer.

The Snap angle

A Snapchat notification is usually a live message, not a marketing digest, so the hard problem is low-latency fan-out and dedup rather than a send-or-not budget. Pinterest or LinkedIn frame this prompt around volume control: you have endless candidate notifications and every send risks costing you the user. Snap inverts that, because the core notifications are transactional. "Alice sent you a Snap" is part of the conversation, it has to land in a second or two, and suppressing it would break the product. So the volume-budget machinery a feed company centers on becomes a small rate-limiter on the side here. The center of the design is delivering real events to a tiny private friend set quickly and exactly once. The path is an extension of live Snap delivery, then, not a recommendation feed deciding whether to bother someone.