Follow-up round: the reply gets lost

The setup

You designed a chat app. Your outbox saves a message, sends it, and marks it as sent when the server says OK.

The question

The interviewer asks: "The server saved the message, but the reply never reached the phone. What happens?"

Stop here and answer out loud for one minute.

A weak reply

"We retry." The interviewer waits, because a retry with no more detail creates a second message.

A strong reply

• The app does not know if the first try worked. A timeout only means it did not hear back.
• The app makes one ID for the message and saves it in the outbox row before the first send. It sends the same ID on every retry.
• The server keeps the first result for that ID and returns it again. The message appears once.

The twist many people miss

The interviewer asks: "The app is killed right after the send. The user opens it again."

A good answer: the ID was saved with the row, so the retry after launch uses the same ID. A new ID here would turn the dedupe into a duplicate. Say that the outbox starts again from the saved rows when the app opens.

Check yourself

• Did you say a timeout is not a failure?
• Did you say where the ID is saved, and when?
• Did you cover the restart?

Score your answer on the score sheet.

Go deeper

• Idempotency keys guide
• Chat app case
• Offline chat simulator: lose a reply, restart the app, and watch the outbox.

All follow-up rounds