Message path
What happens between hitting send and the other person reading it
One message, traced end to end. At each hop: what happens, and what goes wrong when it is built carelessly.
Written as engineering reality for Android chat products, not as a claim about a named vendor stack.
1. Composed on device, written to a local queue
What happens: The message is stored on the handset before the network is trusted. The UI can show a pending state immediately.
What goes wrong: Writing only after a successful round trip leaves the user staring at a blank send when signal dies. Clearing the queue on process death loses the draft forever.
2. Sent, or held if the connection is down
What happens: The client either transmits or keeps the item held with retry rules. Hold is a product decision, not an accident.
What goes wrong: Aggressive retries burn battery and create duplicates. Silent hold with no UI makes users resend and double-post.
3. Received and ordered by the server
What happens: The server assigns identity and order so every device can agree what came first.
What goes wrong: Client-only timestamps reorder threads when clocks drift. Missing server identity makes the same send look like two messages after sync.
4. Stored, and for how long
What happens: Retention, deletion windows and legal hold rules decide what remains after the conversation moves on.
What goes wrong: Unlimited history without a policy blows storage and compliance. Deleting only on one device leaves copies elsewhere that users still believe are gone.
5. Pushed to the recipient's device
What happens: A push wakes or notifies the recipient so the client can fetch or display the new message.
What goes wrong: Treating push as guaranteed delivery hides failures. Collapsed notifications and missing collapse keys bury older messages under noise.
6. Recipient's device asleep, and how Doze changes delivery
What happens: Android Doze and app standby delay background work. High-priority paths and correct channel setup decide whether a chat alert arrives while the screen is off.
What goes wrong: Polling in the background dies in standby. Ordinary priority pushes sit until the next maintenance window, so "instant chat" becomes minutes late at night.
7. Delivered receipt returned
What happens: The recipient client acknowledges that the payload reached the device, and the sender UI can move from sent to delivered.
What goes wrong: Marking delivered on server accept alone lies to the sender. Missing idempotency creates receipt storms when the same ack is retried.
8. Opened and read receipt returned
What happens: Opening the thread (or the message) emits a read state the sender is allowed to see under product rules.
What goes wrong: Firing read on notification expand, or ignoring user privacy settings, breaks trust. Group read semantics without clear rules confuse everyone.
9. Synced to the sender's other devices
What happens: The same account on a second phone or tablet receives the outbound message and its state changes.
What goes wrong: Syncing only inbound traffic leaves the second device missing what "you" already sent. Conflict rules that last-write-wins can erase a receipt state the first device already showed.
10. Deleted, and what deletion actually means on each device
What happens: Delete-for-me, delete-for-everyone, and server purge are different operations. Each device must apply the rule it is allowed to apply.
What goes wrong: A trash icon that only hides a row locally while media stays on the server is not deletion. Offline devices that never receive the delete event resurrect messages on next sync.
