A courier application must work where connectivity is intermittent. What must be designed rather than assumed?

What must be designed

• Local persistence for everything the courier needs: the assignment, the addresses, the customer contact, the item list. A courier standing outside a building with no signal must still know where to go.
• Local recording of what happened — delivered, attempted, refused, collected — queued for submission.
• Idempotent submission, because a courier unsure whether a submission went through will submit again, and duplicate delivery confirmations produce duplicate settlement.
• Conflict resolution for the case where the central system changed while the device was offline: an order cancelled centrally while the courier delivered it. Last-writer-wins is unacceptable here — the outcome must be an exception queue and a human decision.
• A clear indication of what is synchronised and what is pending, since a courier acting on stale information needs to know it is stale.
• Bounded local storage with eviction, since a device used all day accumulates.

What must not be attempted offline

Anything requiring a live authoritative check: a payment authorisation, a customer identity verification, a reassignment that another courier may also be claiming. These must fail explicitly rather than being queued in a way the courier believes succeeded — which is the worst outcome, because the physical action proceeds on a false assumption.

The physical-world consequence that shapes it

Actions cannot be undone. A package handed over cannot be un-handed; a trip made cannot be un-made. The compensation for an incorrect offline action is a return journey with real cost, which is why the exception queue exists and why the conflict cases must be resolved by a person rather than by a merge rule.

The synchronisation design

Sync on reconnection with a bounded batch and a resumable protocol, since a device that was offline for hours has a queue and pushing it all at once against a rate-limited endpoint fails.

And reconcile: compare what the device reported against what the central system holds, because the submissions that failed silently are the ones that produce a discrepancy nobody sees.