Delivery couriers work in areas with intermittent connectivity and must complete jobs regardless. What does offline-first require beyond local caching?

Caching is the easy half

Reading cached data offline is straightforward. The difficulty is that couriers write offline: they accept jobs, mark deliveries complete, capture signatures and photographs, and record failures — and those writes must eventually reach the server, possibly hours later, possibly after someone else acted on the same job.

What it requires

• A durable local store, not memory. The app will be killed by the operating system.
• An operation queue with idempotency keys, so retries after ambiguous failures do not duplicate.
• Operations that are meaningful independent of order where possible, since the queue may drain in a different order than another courier's.
• A conflict policy per operation type. "Delivery completed" and "delivery failed" for the same job from two sources is a genuine conflict needing a rule; a photograph upload is not.
• Server-side reconciliation as the authority, because the client's view of the world may be hours stale.
• Bounded queue growth, with a policy for what happens after very long offline periods — an unbounded queue eventually fills the device and produces a burst on reconnection that must be rate-limited.
• Visible sync status. The courier needs to know what has been submitted and what has not. Uncertainty about submitted work is worse than a visible failure.

The business rules that must move to the device

Anything the courier must be able to decide offline has to be evaluable locally. Whether a delivery can be marked complete, whether a substitution is permitted, what proof is required — if these need a server call, the offline mode does not work for the case it exists for.

That means the rules exist in two places, which is a real duplication cost and needs a strategy: shipping the rules as data the device evaluates is usually better than reimplementing them in client code, because it keeps one definition.

The failure to design for explicitly

A job reassigned while the courier was offline. They complete it, reconnect, and the server has already given it to someone else. There is no technically correct answer — there is only a business rule, and it must be decided in advance rather than during the incident.