Your Friend's Phone Buzzes First. Every Time.
You're both staring at your phones. Same Slack channel, same workspace, same server blast firing at the same instant. Her Android lights up. You wait. Two seconds. Four. Then yours arrives, fashionably late to a party it was technically invited to first.
Four seconds feels trivial until it's a flash sale, a live auction, or a sports score you have money on. Then it feels like the universe has a favourite.
It doesn't. But the plumbing between a server and your lock screen is genuinely messier than most people imagine, and those seconds have real, traceable causes.
The Journey a Notification Actually Takes
A push notification is not a direct call from an app's server to your phone. That mental model is wrong, and it matters that it's wrong.
The app's server sends a message to a push gateway, a middleman that knows how to talk to your specific operating system. Apple devices use APNs (Apple Push Notification service). Android devices use FCM (Firebase Cloud Messaging). These are massive, globally distributed systems, and your phone maintains a persistent, low-power connection to whichever one owns it. When a message arrives at the gateway, it gets forwarded down that open pipe.
So the actual chain: app server, push gateway, cellular or Wi-Fi network, your phone's radio, the OS notification stack, and finally the screen. Five handoffs before you feel the vibration. Each one introduces variance.
Here's a concrete scenario. Priya and Marcus have the same food-delivery app. The restaurant marks both orders ready at the identical millisecond. The app server fires two pushes simultaneously, one to FCM, one to APNs. FCM acknowledges Priya's Android within 80 milliseconds. APNs takes 200 milliseconds to accept Marcus's payload, purely because of which regional server node each request landed on. That gap is baked in before either phone has done a single thing.
Five Reasons the Gap Opens Up
The gateway queue. APNs and FCM process millions of messages per second. Under load, messages queue. High-priority pushes, flagged by the developer, jump the line. Low-priority ones can sit for minutes. If a developer misconfigures the priority flag, a supposedly urgent alert crawls out at the speed of a newsletter. This is more common than developers like to admit, and it's a failure of craft, not infrastructure.
Network path and radio state. Your phone's radio doesn't stay fully awake. Both iOS and Android cycle the cellular modem through active, idle, and dormant states to save battery. A notification arriving during a dormant cycle waits for the next activity window. On LTE that's a few hundred milliseconds. On a congested tower, longer. Two phones on different carriers, or connected to different towers, can be in entirely different radio states at the same instant.
Doze mode and battery optimisation. Android's Doze mode, tightened with every major release, progressively restricts background activity when a phone is stationary and unplugged. A high-priority FCM message can break through. A normal-priority one cannot, and it waits for the next maintenance window, scheduled entirely on the OS's own terms. Manufacturer behaviour compounds this: a Samsung running One UI applies aggressive sleep policies on top of Android's base behaviour, while a Pixel, running closer to stock, handles the same push differently. Same message, different fate.
The persistent connection itself. That low-power pipe between your phone and the gateway has to be maintained. Switch from Wi-Fi to cellular and it drops, then re-establishes. Messages queue at the gateway during the gap. When the connection restores, they flood in together. This is why stepping outside a building sometimes produces a cluster of notifications arriving simultaneously, apparently out of order, because they are out of order. They reached the gateway in sequence. You're just receiving the backlog all at once, like finding a stack of mail someone forgot to slide under the door.
App-side processing. Once the OS hands the payload to the app, the app can do work before displaying anything. Some decrypt content, fetch additional data, or check a local cache. A two-year-old phone running a slower CPU governor to preserve its last 20% of battery might take 90 milliseconds on the same processing step that a current flagship handles in 30. Small. Real.
What People Assume (and Shouldn't)
The most persistent wrong assumption is that notification order reflects server order. It doesn't, reliably. It can't. The system was never designed to guarantee it.
Push notification systems are built for eventual delivery, not ordered delivery. APNs explicitly stores only the most recent notification per app when your device is offline; earlier ones are dropped, not queued. FCM has similar behaviour for collapsed notifications, where multiple messages sharing the same collapse key get merged into one. Developers use this intentionally to avoid ten consecutive "you have a new message" alerts, but the side effect is that intermediate states simply vanish.
This trips up anyone treating notification order as a reliable log of events. It isn't. If you want to know what happened and when, the app's own feed or history tab pulls directly from the server. That's the authoritative record. Notifications are a nudge, not an archive.
And if you keep finding your phone at the back of the queue: heavy battery optimisation on an older device is the most likely culprit. On stock Android, go to Settings, Battery, Battery Optimisation, find the app and set it to Unrestricted. On Samsung, it's buried in Device Care. It genuinely changes behaviour, not just in theory.
The Four Seconds Are Doing a Lot of Work
Every link in that chain introduces jitter. Gateways, radio states, Doze cycles, app processing. Most of the time the jitter is small enough to be invisible. The times you notice it are exactly the times the stakes feel highest, which is why four seconds can feel like an accusation.
The engineers who built these systems made a reasonable trade: battery life and network efficiency in exchange for strict ordering guarantees. For 99% of notifications, that trade is completely invisible. For the 1% where timing genuinely matters, the deeper truth is that notifications were never the right tool to begin with.
Your friend's phone buzzing first isn't luck, and it isn't a better phone. It's just which radio state her device happened to be in when the gateway came knocking.