STANDARDwalkthrough
Collapse Keys and Notification Coalescing
A user's post goes mildly viral: 50 likes arrive in 2 minutes. Naively that is 50 push notifications, 50 buzzes, and one furious user disabling push forever.
Which of them still matter when the phone reconnects? Only the newest.
“Meanwhile their phone was in a dead zone for the first minute, and 20 of those pushes queued at FCM.”
Two mechanisms fix this, one on each side of the provider boundary. Server side: coalescing windows.
For collapsible event types (likes, follows, unread counts) the notification service holds a short aggregation window (30 to 120 seconds) keyed by . New events update the pending payload in place: "Priya and 49 others liked your post".
One push leaves the window, not 50. Provider side: collapse keys.
APNs calls it apns-collapse-id, FCM calls it collapse_key. Messages sharing a collapse key replace each other in the provider's delivery queue: our dead-zone user receives only the final "50 likes" version on reconnect, not a 20-push burst.
The unread-badge count is the canonical use: every update carries the same collapse id, so the device only ever applies the latest count. The numbers: coalescing collapses roughly 60% of engagement volume in like-heavy products, cutting P1 sends from 3B to about 1.2B/day, which directly cuts provider spend and gateway fleet size.
The trade-off: a coalescing window adds up to 120 seconds of latency to collapsible types, so classification matters: a direct message must NOT coalesce (each one matters), a like should. What if the interviewer asks: what limits collapse keys?
FCM retains only 4 distinct collapse keys per device in its offline queue, so we reserve them for genuinely replaceable streams rather than assigning one per event.
Related concepts