Delivery guarantees and message ordering
Never lose a message, never show them out of order.
Alice sends 'running late', then 'ignore that, I'm here'. Bob sees them in the opposite order and goes home. For chat, correctness is mostly about two promises: every message arrives, and messages in a conversation appear in the same order for everyone. Networks give neither promise for free, because packets are lost, retried and reordered.
Delivery guarantees come in three flavours. At-most-once sends once and forgets: fast, but messages can vanish. At-least-once retries until the receiver acknowledges, so nothing is lost, but duplicates happen when an acknowledgement is lost. Exactly-once is what users want, and the practical way to get it is at-least-once delivery plus deduplication by a unique message id. The receiver notices an id it already processed and ignores the repeat.
Sending a chat message reliably
Step 1 of 4
Client creates an id
Before sending, the client generates a unique id for the message (a UUID). Retrying the same message always reuses that id.
Why a sequence per conversation rather than timestamps? Device clocks disagree by seconds, and two messages can share a millisecond. A single counter per conversation, assigned wherever messages are appended, is unambiguous and cheap. Ordering is only needed within a conversation, not globally, which means different conversations can be handled on different machines in parallel; route all messages for one conversation to the same log partition to keep their order.
Your turn
Describe what happens, step by step, if the sender's phone sends a message, the server saves it, but the acknowledgement is dropped. Show how the user ends up seeing exactly one copy.
Stuck? Think about the retry and what the id does.
What to remember
At-least-once plus dedup by id gives exactly-once effect.
Clients retry with the same message id.
The server assigns a sequence per conversation to define order.
Keep a conversation's messages on one partition to preserve order.