Mobile connection loss: the 3 possible strategies

Open WhatsApp inside a subway tunnel and send a message. A small grey clock appears next to the text. The message stays in the interface. The queue takes over. When you exit the tunnel, the clock becomes a single ✓, then ✓✓ when the recipient’s device receives it.

Across more than 3 billion monthly users in 2025 (Backlinko — WhatsApp Users 2026, source Meta Q1 2025), this detail is probably the most-seen mobile product decision in the world. It condenses one answer — among three possible ones — to the question every mobile team eventually asks: what should the application do when the network drops while the user is saving an action?

Three strategies exist. Each modifies the user experience, the technical complexity, and the nature of the trust contract with the user. The senior mobile developer’s mark is not knowing how to implement all three — it is knowing how to arbitrate between them, action by action.

Why mobile forces this choice

An intra-datacenter backend experiences rare network partitions. A mobile app connected to that same backend is always in a potential partition regime: tunnel, elevator, cell handover, saturation, roaming. Network loss is not an edge case on mobile — it is a regular state.

The CAP theorem, posed by Eric Brewer in the PODC 2000 keynote then formalized by Seth Gilbert and Nancy Lynch at MIT in 2002 (Gilbert & Lynch, ACM SIGACT News 2002), states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition tolerance. In practice, P is non-negotiable; the real choice is therefore between C or A during a partition.

Translated to mobile:

• Choose C → if the network drops, refuse the action or wait. That is strategy 01 (Block).
• Choose A → if the network drops, accept the action locally, reconcile later. That is the basis of strategies 02 and 03.

CAP does not say you must choose C or A once and for all for the entire app. It says that at each operation in a partition regime, a choice is made — implicitly or explicitly. The senior mobile developer’s role is to make that choice explicit and documented.

Strategy 01 — Block

The application refuses to accept the action until server confirmation arrives. The UI stays in its pre-action state, with a spinner, until the server responds or a timeout fires.

Notion’s early onboarding refused offline edits — this was a recurring criticism for years, until native offline shipped in August 2025 (version 2.53) (XDA Developers, August 2025). That absence was a documented commercial hurdle versus Apple Notes and Obsidian. Notion did not use strategy 01 on principle — the team acknowledged the limit but treated it as lower priority than other work.

The message is clear: defaulting to blocking is not a neutral choice. On any non-critical action, it is debt paid in churn.

Strategy 02 — Local queue + sync (outbox pattern)

The application saves the action immediately in a local database (SQLite, Isar, Drift, Hive, Realm) within the same transaction as an entry in an outbox table. The UI reflects the local state. An asynchronous worker consumes the outbox and syncs with the server, with retry and exponential back-off.

The transactional outbox pattern was formalized by Chris Richardson for microservices architecture (microservices.io — Transactional Outbox (Chris Richardson)) to solve the dual-write problem: guaranteeing that an event published in a broker stays consistent with the state written to the database. The mobile problem is structurally identical — guaranteeing that a deferred API call stays consistent with the local state the user sees on screen.

Case study: WhatsApp

WhatsApp is probably the most visible implementation of this strategy in the world. When the network drops:

1. The message is written immediately to local SQLite with a client_id UUID
2. The grey clock icon indicates “waiting to send to server”
3. A worker retries periodically — as soon as the network returns, sending succeeds

The transition to the following icons (✓ = server received, ✓✓ = delivered to recipient device, ✓✓ blue = read) delivers the 4 mandatory UX states in a single visual cell (LINK Mobility — What do WhatsApp check marks mean?). This icon system probably contributed to WhatsApp’s success on markets with irregular connectivity — India, Brazil and Indonesia are the top three WhatsApp markets by user count.

Case study: Google Docs

Since the HTML5 Chrome App introduced in August 2011 (TechCrunch, August 31, 2011), Google Docs applies a mobile variant of strategy 02: modifications are written locally (IndexedDB on web, local structures on mobile), and a worker syncs as soon as the network returns. For multi-user collaboration, the merge uses a variant of reconciliation algorithm (historically Operational Transformation, algorithms closer to CRDT today — see Shapiro et al., SSS 2011 (Shapiro et al., SSS 2011 (LIP6))).

Strategy 03 — Optimistic UI

The application immediately reflects the presumed result of the action in the UI — as if the server had answered OK — then fires the actual call in the background. On success, no visible change. On failure, silent or explicit rollback of the UI.

Sequence of optimistic UI (the like):

The Instagram like is the most cited case study in UX pedagogy (DEV Community — Optimistic UI Updates Explained): the tap on the heart triggers the animation before the API call. This strategy brings perceived feedback under 100 ms — the instantaneous perception threshold established by Robert Miller in 1968 and reprised by Jakob Nielsen in Usability Engineering (1993) (Nielsen Norman Group — Response Times: The 3 Important Limits) — regardless of network state.

Difference with strategy 02: the data is not necessarily persisted locally. On failure, it disappears without trace — that’s the assumed risk. Both strategies can be combined: optimistic UI for immediate rendering + outbox for persistence and retry. That’s exactly what Instagram does on comments, WhatsApp on messages, and Slack on reactions.

The decision grid

Strategy choice is not a doctrine — it is a 2×2 matrix to re-read at every new product action:

A single app typically occupies all four quadrants. Take a banking app:

• Like on a marketing push notification → Optimistic
• Editing an account nickname → Local queue
• Sending a message to the advisor → Local queue
• SEPA wire transfer → Block

Conflating plans (“we do offline everywhere” or “we do everything optimistic”) produces technical debt that becomes structural.

The 4 mandatory UX states

Any strategy that is not “Block” imposes explicitly communicating to the user the state of their data. Four states are necessary and sufficient, with well-defined transitions:

Five anti-patterns to watch

What to do this week

Take the last five features shipped by the team. For each, write in one sentence the strategy used: “block”, “local queue”, “optimistic”. Then check two things:

1. Is the choice explicit? Documented somewhere, or implicit in the code with no one able to name it?
2. Does it match the matrix’s expected cell? A wire transfer in optimistic is an incident waiting to happen. A like in blocking mode means three users uninstall every week.

If no one knows, it’s probably block-by-default — and it shows in the NPS.

Primary sources

• Gilbert, S. & Lynch, N. — « Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services », ACM SIGACT News, 2002.
• Richardson, C. — « Pattern: Transactional outbox », microservices.io.
• Shapiro, M., Preguiça, N., Baquero, C., Zawirski, M. — « Conflict-free Replicated Data Types », SSS 2011, LNCS 6976.
• Backlinko — « WhatsApp User Statistics 2026 » (Meta Q1 2025 earnings — 3 B MAU).
• XDA Developers — « Notion’s offline mode is finally here », August 2025.
• Nielsen, J. — Usability Engineering, Academic Press, 1993 (thresholds 100 ms / 1 s / 10 s, chapter 5).