Designing for Offline and Poor Connectivity

The plain-language idea

The mechanism for offline support — a Service Worker intercepting requests and serving cached responses — is covered elsewhere in this platform, and this lesson assumes it as a given tool, not something to re-derive. The system design question is different: given that the mechanism exists, what do you actually design with it? Three decisions do most of the work:

• Scoping what needs to work offline. This differs completely by product, and naming that scope explicitly is the first move, not an afterthought. A note-taking app might need full offline read-and-write. A checkout flow might only need to gracefully show "you're offline, try again" rather than pretend to work. Trying to make everything work offline is usually the wrong instinct — it's a scoping decision, same as any other requirement.
• An outbox pattern for offline writes. When a user takes an action while offline (send a message, save an edit, submit a form), the write can't reach the server yet. An outbox queues that action locally and replays it once connectivity returns, in the order it was queued. This turns "the network is down" from a hard failure into a deferred success — the user's action isn't lost, it's just pending.
• Honestly communicating connectivity state. A UI that pretends everything is normal while actually offline, silently queuing writes with no visible signal, sets the user up to be confused later about what actually saved. A UI that's upfront ("you're offline — this will send once you're back online") sets the right expectation from the moment the action is taken.

See it in a real thing: a messaging app sending while offline

Say a user types a message while their connection drops. A shallow design either blocks sending entirely (a hard failure that loses the user's intent) or silently pretends it sent (which breaks the moment the message never actually arrives and the user has no idea why). The stronger design: the message appears immediately in the thread with a visible "sending…" state, gets added to a local outbox, and the outbox replays it as soon as connectivity returns — at which point the state updates to "sent" or, if it genuinely fails, to a clear "failed to send, tap to retry."

What people usually miss

Watch out

• "Make it work offline" isn't a single requirement — it's a scoping question per feature. A strong answer asks which parts of the product genuinely need offline support before designing anything, rather than assuming the whole app does.
• A silent failure is worse than an honest one. A write that fails silently while offline, with no visible signal to the user, is a worse experience than a UI that's upfront about the connection state and what will happen once it's restored.
• The outbox needs a conflict story too, not just a retry story. If an offline edit and someone else's online edit to the same resource both land, that's the same conflict-resolution problem covered in the optimistic-updates lesson — worth naming the connection rather than treating offline writes as a wholly separate topic.
• Re-explaining Service Worker mechanics in this kind of interview answer is a wasted opportunity. The mechanism is assumed knowledge; the actual signal a candidate gives is in the scoping, outbox, and communication decisions built on top of it.

Why this matters in interviews

"How would you make this feature work on a flaky connection?" tests whether a candidate reaches for scoping, an outbox pattern, and honest connectivity signaling as deliberate design decisions, rather than treating "add a Service Worker" as a complete answer on its own.