Two phones behind carrier networks, changing IPs, falling asleep — they can’t talk directly. How do they exchange messages?

1. Rejected. Peer-to-peer: the phones connect directly to each other.

   Phones hide behind NAT/carrier networks, change IPs, and sleep — a direct connection rarely works and breaks constantly. You need a reliable middleman both can always reach.

2. The call. A server in the middle that stores then forwards each message.

   Alice sends to the server, which holds a copy in a Message Store and forwards to Bob. Store-and-forward — holding each message until the recipient has it — is what lets messaging survive flaky networks and sleeping phones.

3. Rejected. Email the message to the recipient.

   Email is slow, not real-time, and a different system. Chat needs an instant relay that tracks delivery — a server that stores and forwards.

The server holds Alice’s message, but Bob’s phone isn’t asking for it. How does it arrive instantly?

1. Rejected. Bob’s phone polls "any messages for me?" every second.

   Billions of phones polling every second is a self-inflicted DDoS that still feels laggy (you wait a poll interval). The server should push the instant a message arrives.

2. Rejected. Send Bob a push notification to open the app.

   Push notifications wake a closed app, but in-chat delivery needs a live two-way pipe for messages, typing and receipts — not a nudge to reopen. Keep a persistent connection while online.

3. The call. A persistent WebSocket per phone; the server pushes on arrival.

   An always-open socket flips the model — the server speaks first, delivering the moment a message lands, with no polling. One warm pipe carries messages, typing dots and receipts both ways.

There are thousands of connection servers. Alice is on #14, Bob on #882. How does #14 deliver to Bob?

1. Rejected. Server #14 broadcasts the message to all connection servers.

   Shouting to thousands of servers per message is hugely wasteful and doesn’t scale. You want to deliver to exactly one place — the server holding Bob’s socket.

2. The call. A Session Service maps user → connection server; look Bob up and route.

   When Bob connects he registers his spot; to deliver, #14 asks "where’s Bob?", finds #882, and routes straight there. Service discovery turns "shout to everyone" into "deliver to exactly one place" — a fast in-memory registry (Redis).

3. Rejected. Pin every user to a fixed connection server forever.

   Phones roam, reconnect and load-balance across servers constantly, so a fixed assignment breaks the moment Bob reconnects elsewhere. The registry must update on every connect/disconnect.

Bob’s phone is off or has no signal — there’s no socket to push to. What happens to the message?

1. Rejected. Alice’s phone keeps retrying until Bob comes online.

   Making the sender retry for hours/days drains Alice’s battery and blocks her on a sleeping recipient. The server should absorb the wait, not the sender.

2. Rejected. Drop the message and ask Alice to resend later.

   Silently dropping messages is unacceptable — delivery must be reliable. The message has to be held safely until Bob reappears.

3. The call. Queue it in Bob’s per-user Inbox Queue; drain on reconnect, then delete.

   If the registry shows no live connection, the message waits in Bob’s mailbox; the moment he reconnects the server drains the queue to his phone, confirms delivery, and deletes the stored copy. The queue decouples send from receive.

Alice posts in a 50-person group. How does everyone get it, in order, without her phone sending 50 copies?

1. The call. She sends one message; a Group Service fans it out to each member.

   One message tagged with the group id; the Group Service looks up members and fans out a copy to each one’s connection (or Inbox Queue if offline). One send in, N deliveries out, all server-side — fan-out on write.

2. Rejected. Her phone sends a copy directly to all 50 members.

   Client-side fan-out is slow and drains her battery, and her phone doesn’t know everyone’s connection server. Fan-out belongs on the server, which knows where each member is.

3. Rejected. Everyone polls a shared group inbox for new messages.

   Polling a shared inbox reintroduces the lag and load you removed with push, and complicates per-member delivery/receipts. Push a fanned-out copy to each member instead.

A 50 MB video can’t ride the same lightweight pipe as "lol 😂". How do you send media?

1. Rejected. Stream the video through the connection server like a big message.

   Pushing big blobs through the real-time connection servers clogs the messaging path for everyone. Text and media need different roads.

2. Rejected. Split the video into chunks and send them as many chat messages.

   Cramming a video into the message pipeline as chunks still loads the real-time path and the message store with huge data. Media should bypass the chat pipeline entirely.

3. The call. Upload once to blob storage + CDN; the chat carries a pointer + thumbnail + key.

   Media uploads once to blob storage fronted by a CDN near each viewer; the message carries only a small pointer, thumbnail and decryption key, and Bob fetches the blob from the nearest edge. Separate the data plane from the control plane.