Design Real-Time Messaging

"Design real-time messaging" is Apple's spin on the chat prompt. It surfaces as iMessage delivery, FaceTime call setup, or "design APNs," the Apple Push Notification service. The task sounds small. One person sends a message to another, and it appears almost instantly. But the recipient does not own one device. They own an iPhone, an iPad, and a Mac, and the same message has to land on all of them. Some are awake and online, some are asleep in a bag, and the sender neither knows nor cares which. That split, delivering to several devices at once across an online/offline divide, is the interview hiding inside one sentence.

Picture it concretely before you design anything. You send "running late" to a friend. Their iPhone is in their pocket with the app open, their iPad is asleep on the couch, and their Mac is closed at the office. The message has to reach the phone within about a second, sit safely waiting for the iPad and the Mac, and appear correctly on each one the moment it wakes. Nobody resends. No device misses the message, and none of them shows it twice. And the server that moves all of it never learns what the message says. That quiet, reliable, private delivery is the product, and it is harder than it looks the moment one recipient has several devices that are rarely all online at once.

Now the scale. Apple serves hundreds of millions of messaging users, and a typical person owns several devices each. The traffic is a firehose of tiny encrypted messages, each one fanned out to every device the recipient owns. A single send can become three or four separate deliveries, one per device, and every one of those is a small blob the server cannot read. Billions of these flow every day. So the system is built around routing huge numbers of small ciphertext messages reliably to many devices, not around raw throughput on big blobs.