Background Sync is implemented only in Chromium browsers. For a field-service web app whose technicians submit reports from areas with poor connectivity, on Android and iOS alike, how would you design the offline write path?

## Framing the decision The temptation is to compare APIs. The better framing is that Background Sync only changes *when* a flush is attempted; it never changes what must be true for the flush to be safe. So the architecture is the same everywhere, and platform support only determines how promptly the queue drains. That reframing is what a principal-level answer is expected to supply, because it turns an unfixable capability gap into a difference of degree. ## Layer 1 — the durable outbox A write is accepted into local storage before the network is touched. IndexedDB is the right store: it is asynchronous, holds structured records and blobs (field reports mean photos), and is not capped at a few megabytes of strings. Each entry carries the payload, an idempotency key generated at enqueue, a created timestamp, an attempt count, and a status. Two consequences follow immediately. First, the UI can only ever claim *queued*, never *saved*, until the server acknowledges. Second, the outbox is user data, so it inherits real obligations — it can contain personal information sitting on a shared device, and it is subject to storage eviction. That argues for requesting persistent storage where available and for a retention policy that discards or escalates entries beyond a certain age rather than retrying forever. ## Layer 2 — idempotency at the server Because every trigger may fire while another attempt is in flight, and because a response can be lost after the server committed, the server must be able to recognise a repeat. A client-generated key on the record, honoured server-side for a defined window, converts an at-least-once delivery pipeline into an effectively-once one. Without it, the more reliable your retry triggers are, the more duplicates you create — the failure mode gets worse as the client gets better, which is why this layer comes before any discussion of triggers. ## Layer 3 — the trigger ladder One flush function, many callers: ```js async function flushOutbox() { if (flushOutbox.running) return flushOutbox.running; // single-flight flushOutbox.running = drain().finally(() => (flushOutbox.running = null)); return flushOutbox.running; } window.addEventListener('online', flushOutbox); document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'visible') flushOutbox(); }); window.addEventListener('load', flushOutbox); ``` And on Chromium, additionally, a `sync` registration so the same drain runs in the service worker with no page open. Every trigger calls the same code path, guarded by single-flight so overlapping triggers cannot double-send. What this ladder buys per platform is worth stating plainly in an interview: on Chromium a queued report can leave the device while the app is closed; on iOS Safari it leaves the next time the user opens the app with signal. For technicians who open the app several times a day, that difference is hours, not days — and knowing that is what decides whether the gap is acceptable rather than a reason to go native. ## Layer 4 — honest UI The most common real-world failure of offline apps is not lost data; it is a green checkmark shown for data that never left the device. The queue must be visible: a pending count, per-item state, a manual *retry now*, and an explicit warning before the user signs out or clears data with items outstanding. On iOS the app should nudge — "3 reports waiting to upload, keep the app open a moment" — because the user is the trigger there. ## Layer 5 — measurement Instrument time-from-enqueue-to-acknowledged as a distribution, per platform; the count of entries older than a threshold; flush attempts per success; and eviction events. Without this, the iOS/Chromium difference is an argument in a meeting rather than a number. With it, the team can decide whether pushing users to install the app — which on iOS also unlocks push from iOS 16.4 — is worth the friction. ## What I would not do I would not build two code paths, one Background-Sync-shaped and one not; the divergence rots. I would not put pending writes in `localStorage`, which is synchronous, small and string-only. I would not retry indefinitely without a ceiling, because a permanently poisoned record then blocks the queue forever — failed items move to a dead-letter state visible to the user and to support. And I would not treat the offline path as a feature to add later: the outbox has to be the only write path from day one, or half the codebase will keep calling `fetch` directly and the guarantee will be a fiction.