EASYwalkthrough
Quiet Hours and Timezone Batching
A user in Mumbai gets a price-drop push at 3:14 AM because the campaign was scheduled for "9 AM" in the company's home timezone. Nothing else in the system matters to that user anymore; they open settings and disable push.
Implementation: every user row stores an IANA timezone (from device settings, refreshed on app launch, 500M rows already in the preference store). At send time, P2 and batchable P1 messages compute the recipient's local hour; anything inside the quiet window is deferred, not dropped: the message is parked with a delivery-after timestamp at the next local 08:00 and re-enters the send path then.
“The rule is simple to state and easy to botch: non-urgent notifications respect the recipient's local night, typically 22:00 to 08:00 in the user's timezone, not the server's, not UTC.”
This turns the morning boundary into a predictable thundering herd: hundreds of millions of deferred messages all become eligible at 08:00 local, marching around the globe timezone by timezone. We flatten it by jittering release over a 30 to 60 minute window and letting the campaign scheduler pre-shard sends by timezone bucket in the first place: "deliver at recipient's 9 AM" becomes 24+ staggered waves rather than one spike.
P0 always bypasses quiet hours: an OTP requested at 3 AM was requested by the user at 3 AM. The trade-off: deferral plus daily budgets interact; a deferred message competes for the next day's budget, so ordering (defer, then budget-check at release) must be explicit or users get nothing at 08:00.
What if the interviewer asks: what about users who travel? The device reports its current timezone on each launch; a stale timezone degrades gracefully to at most one mistimed push, and the 270-day token backstop already bounds abandoned devices.
Related concepts