Edge, Mobile, and Intermittently Connected Systems

Mara edits a field report on her phone after the train enters a tunnel. The title changes from “North pump” to “North pump inspection,” a photo begins uploading, and a checkbox marks the pump unsafe. The interface applies each local operation in 18 ms and shows a pending-sync indicator.

At the same time, Jo opens the earlier report on a tablet at the site office. The tablet has connectivity but has not yet received Mara’s operations. Jo corrects the equipment identifier and changes the same title to “Pump 7 inspection.” Both devices later reconnect.

No timeout can decide the right merged report. A later wall-clock timestamp does not prove which title should win; the clocks may differ and the edits are concurrent. The equipment identifier changes independently and can merge if fields and schema agree. The unsafe checkbox may represent a safety workflow that must never be cleared by a generic object merge. The photo upload can resume from acknowledged chunks without deciding any field conflict.

The system succeeds only if it separates four promises:

1. local response: the device preserves the user’s intent durably enough for its threat and crash model;
2. synchronization: every operation has identity, authority, compatibility, and a bounded retry/reconciliation path;
3. user truthfulness: pending, synced, conflicted, stale, rejected, and failed are visibly different states; and
4. fleet safety: old clients, constrained devices, private telemetry, background limits, and slow rollbacks remain part of the design.

Moving work toward the user can remove a round trip. It cannot remove authority, conflict, or completion semantics. The governing rule is: place work and state near the user when it improves responsiveness without making authority, reconciliation, privacy, and version skew unmanageable.

Design for a population, not a reference phone

A mobile fleet differs in CPU architecture, core count, memory pressure, storage performance, radio, screen, battery health, thermal envelope, operating-system policy, and installed application version. One user may alternate between a low-memory phone, tablet, browser, and managed rugged device. “The client” is a distribution.

Create supported-device cohorts and preserve tails:

hardware: architecture, memory class, storage free space, battery/thermal class
software: OS and app version, schema/protocol capabilities, security patch floor
network: Wi-Fi/cellular/roaming, bandwidth/loss/RTT, metered state, reachability
usage: foreground/background, session length, sync age, locale, accessibility
data: local-state size, pending operations, media, cache age, privacy class

Measure cold and warm launch, time to interactive, frame or input delay, local database latency, sync age, transfer bytes, CPU time, memory high-water, disk growth, radio-active time, battery impact, thermal state, and task termination. Segment by privacy-safe cohort. An average from current flagship devices can conceal a memory crash on supported low-end devices; a lab Wi-Fi median says little about roaming loss.

Thermal and power state change available performance during a session. Sustained image processing can begin fast and throttle later. Background work may be delayed or terminated by the operating system. Treat those as scheduling inputs. Reduce concurrency, defer optional indexes, lower prefetch, or move work to a server when the device is hot or low on power. Do not let lower local quality silently change a correctness-critical result.

Connectivity is a changing capability

Reachability is not successful completion. A device can have an interface and fail DNS, TLS, authentication, captive-portal, request, or response delivery. It can send a mutation whose response is lost, roam to another network, sleep, and retry hours later. Bandwidth and loss can change within one transfer.

Model network envelopes rather than “online/offline” alone:

Request retries need stable operation identity. If the server committed Mara’s unsafe operation but the acknowledgment was lost, retry must return the existing outcome rather than toggle the field or create a second alert. Backoff and jitter protect servers during recovery, but the device must persist the retry schedule and stop when the operation becomes obsolete, unauthorized, incompatible, or explicitly conflicted.

Local-first, offline-first, and cache-first are different contracts

Local-first makes the local store the immediate interface for reads and writes. Synchronization connects replicas later. This gives responsive interaction and explicit pending work, but multi-device authority and conflicts become core product semantics.

Offline-first promises useful behavior without a network for a declared set of operations and duration. It may use a local authoritative work log, a cache, downloaded data, or all three. It does not require every feature to work offline.

Cache-first serves a derived local copy when eligible, then validates or refreshes it. The origin remains authoritative. A cache miss or expired entry can prevent the operation. Cache-first alone does not authorize offline mutation.

State the contract per operation:

The offline envelope includes maximum age, local storage and encryption, allowed mutations, authentication lifetime, revoked-access behavior, conflict policy, and recovery. A device that has been offline beyond its authorization or schema window may allow local export while refusing new governed mutations.

Synchronize operations with explicit authority

A reliable client records an operation before presenting it as locally saved:

operation_id       stable across retries
actor/device       authorized identity and local device generation
object_id          synchronization scope
base_version       authoritative generation observed before editing
schema_version     operation decoder and invariant version
operation          semantic mutation, not necessarily an object replacement
local_sequence     durable device ordering
dependencies       required prior operations when applicable
created_monotonic  local scheduling evidence, not global authority
privacy_class      storage, transfer, and telemetry constraints
state              pending | sent | accepted | conflicted | rejected

The server deduplicates operation_id, verifies authorization and schema, checks the operation against current state and invariants, commits or returns a named conflict/rejection, and responds with an authoritative version plus any missing operations or snapshot reference. The client applies acknowledgments transactionally with its pending log so a crash cannot forget an accepted operation and resend it as new work.

An offline edit sequence can be:

1. device A reads report version 40 and appends operations a1, a2, and a3 locally;
2. device B also reads version 40 and appends b1 and b2;
3. B reconnects, and the authority accepts compatible b1, then records b2 under title-conflict policy, producing version 42;
4. A reconnects with base 40; the authority deduplicates any prior attempt, returns operations since 40, and evaluates A’s operations against version 42;
5. independent equipment-ID and photo-reference operations merge if their invariants permit; concurrent title edits become one explicit conflict; the unsafe operation enters the safety workflow; and
6. both clients receive a snapshot or ordered deltas at an authoritative generation and retain unresolved conflict state until policy or a user resolves it.

The sequence needs a snapshot boundary and bounded log retention. If version 40 is older than retained deltas, return “snapshot required”; never send a partial suffix as complete history. Snapshot identity includes schema, authorization scope, and position. After replacing a projection at position p, the first legal delta is greater than p in the same generation.

Conflict policy follows the invariant

Conflict resolution is not one algorithm. Choose the unit and semantics:

• version rejection is appropriate when the user must reconsider against current truth;
• field merge works when fields are independent and old clients cannot violate cross-field invariants;
• operation merge works when operations are defined to commute or have a deterministic invariant-preserving order;
• single-writer or ownership transfer avoids concurrent authority for sensitive state;
• explicit conflict preserves alternatives for a user or workflow decision; and
• last-write-wins deliberately discards one value and is safe only when that loss is acceptable and the ordering source is justified.

Conflict-free replicated data types encode merge properties for particular state and operation models. They can provide convergence under their assumptions; they do not decide business validity, authorization, deletion, privacy, schema migration, or which concurrent intent deserves product precedence. An unsafe flag could use monotonic escalation until an authorized inspection clears it, while report prose exposes a human conflict. The two fields need not share a merge law.

Never use device wall time as an unexamined global winner. Clocks move, and later synchronization time does not mean later user intent. Preserve causal/base-version evidence and a deterministic tie-break only where the application explicitly permits loss.

Deltas, compression, prefetch, and resume spend different budgets

The Fieldnote fixture compares an 8 MiB full report state with a 180 KiB delta compressed to 72 KiB. On a modeled 256 Kibit/s application path, the full state takes 256 seconds before protocol overhead, retransmission, or slow start; the compressed delta takes 2.25 seconds. It transfers 113.78× fewer bytes. This is a teaching boundary, not a universal compression ratio.

A delta is valid only against its declared base. If the client lacks that generation, fetch a compatible chain or snapshot. Compression spends CPU, memory, and possibly dictionary state; measure on low-end devices and hostile inputs. Encrypt after compression under an appropriate security design, avoid cross-authorization compression contexts, and bound decompressed size to prevent resource exhaustion.

Prefetch when probability of use times avoided delay justifies bytes, storage, energy, freshness risk, and privacy exposure. Prefer small manifests and likely next items; cancel obsolete prefetch. A content launch may justify Wi-Fi/charging prefetch, while speculative cellular video does not. Cache keys and stored files include user/tenant, authorization, content version, transformation, and encryption scope.

For large transfer, create a stable upload identity and chunk manifest. The fixture splits 12 MiB into forty-eight 256 KiB chunks. If thirty-six verified chunks were durably acknowledged before disconnection, reconnect uploads twelve remaining chunks and avoids retransmitting 9 MiB. Define whether chunk acknowledgment means device-edge receipt, regional durability, or final authority. Completion verifies the manifest and checksum, publishes atomically, and makes repeated completion idempotent. Expire abandoned uploads and prove garbage collection cannot remove chunks still referenced by a live manifest.

Delta sync and resumable upload solve different failures. A delta reduces logical change bytes; chunks prevent a transport interruption from replaying already verified bytes. Use both where media metadata changes alongside a large object.

Background and battery budgets are scheduling inputs

Mobile operating systems control when background work runs and may combine, delay, or stop it. Code must checkpoint, respond to cancellation, avoid assuming exact periodic execution, and leave a durable state from which a later run resumes. Use platform schedulers and their network/charging constraints rather than maintaining a wake loop.

Energy is a whole-device measurement problem. Radio promotion and tail time, signal strength, CPU, storage, display, GPS, encryption, compression, retries, and thermal throttling interact. A component’s nominal wattage is not an application result.

The fixture gives a 14 Wh battery 50,400 J. An illustrative hourly sync budget of 0.5% is 252 J. One modeled sync uses a 1.8 W radio for 12 seconds and 0.9 W of CPU for 4 seconds, or 25.2 J before overlap and unmodeled device work. Eight syncs consume 201.6 J and leave 50.4 J of the teaching budget. If reconnect retries double radio-active time, the plan fails despite identical payload semantics.

Use a priority ladder:

1. user-initiated foreground operations and safety/security acknowledgments;
2. pending mutations required to preserve cross-device intent;
3. small freshness validation needed for the next likely interaction;
4. bounded telemetry and maintenance; and
5. optional prefetch, compaction, or derived indexes when charging/unmetered.

Coalesce superseded background refreshes. Do not coalesce distinct durable user operations unless their semantic key explicitly permits replacement. Stop when the OS expires the task, persist a cursor, and continue later.

Edge placement shortens paths but adds another failure domain

An edge tier may terminate transport, authenticate, cache immutable content, execute stateless transformations, aggregate telemetry, or host a derived model. A regional tier may hold user affinity and synchronization logs. The origin may remain mutation authority.

For each operation, draw device → access edge → region → origin and label:

• authoritative, derived, cached, ephemeral, or staged state;
• normal and fallback route;
• authorization and encryption boundary;
• version/freshness semantics;
• acknowledgment meaning;
• failure and retry behavior; and
• residency and deletion responsibility.

Running code at an edge helps only if data, runtime, and policy are available there. A cache hit can reduce content latency; a write routed through an edge still needs authoritative coordination. An edge can accept resumable chunks nearby while clearly saying “staged,” then publish only after the destination’s durability rule. A disconnected edge cannot invent authority unless the domain has an explicit delegated lease, invariant, and reconciliation protocol.

Fallback should be semantic, not merely a longer route. If an edge transform fails, the device may use a compatible local approximation or the origin. If a regional synchronization authority is unavailable, local operations remain pending rather than being acknowledged by an uncoordinated cache. Protect origin from synchronized fallback by admission, jitter, stale eligibility, request collapse, and cached immutable snapshots.

Optimistic UI must remain honest

Fieldnote’s local apply is modeled at 18 ms versus an 850 ms connected round trip, a 47.22× response ratio and 832 ms of avoided waiting. The user can continue working even when the network takes longer or disappears. That is perceived-performance improvement because the system changed the interaction path, not because it hid latency.

Use distinct milestones:

0 ms      tap / edit intent
18 ms     local operation durably recorded; UI shows pending
...       synchronization scheduled; user may leave
850 ms    example authority response if currently connected
later     UI shows synced, conflicted, rejected, or retrying

An optimistic projection must be reversible or reconcilable. Preserve the user’s input when rejection occurs. Avoid celebratory “sent,” “paid,” or “approved” language at local commit if the authority has not accepted the outcome. Accessibility must expose state without relying only on color or animation.

Perceived performance also includes skeletons, incremental rendering, stable layout, progressive images, local search, and cached navigation. Each technique needs a completeness signal. A skeleton that never resolves is failure; a partial list must not look complete if missing items change a decision.

Freshness includes stale usability

Freshness is scoped by object, operation, user, and consequence. Record fetch time, authoritative generation or validator, freshness lifetime, maximum stale use, and invalidation signals. Expiry means revalidation is required for a fresh claim; it does not by itself erase stored bytes or decide whether stale data remains useful.

The fixture’s content is five hours old. It is outside a one-hour fresh window but inside a 24-hour read-only stale allowance. The client may show it with an explicit age and offline status, while disabling decisions that require current safety or price state. A revoked credential, deletion, emergency invalidation, or schema incompatibility can override the stale allowance.

Choose stale behavior by consequence:

Long-lived clients turn rollout into protocol evolution

Servers can often route back quickly; installed clients may remain old for months and can be offline during a migration. The fixture models 70% current, 22% previous, and 8% legacy clients. A server that removes the legacy decoder after observing only the 70% current cohort breaks 30% of the declared population.

Every request announces protocol/schema capabilities rather than relying only on an app version string. Add fields compatibly, preserve unknown data when round-tripping requires it, and gate behavior by negotiated capability. Server responses should stay within the client’s declared decoder. Operations created offline must remain interpretable when uploaded later or receive an explicit migration/export path.

Use expand–migrate–contract:

1. deploy readers that accept old and new forms;
2. emit the new form only to capable clients;
3. measure successful parsing, synchronization, and quality by supported cohort;
4. migrate stored local/server state with resumable evidence;
5. wait through the maximum offline and upgrade window; and
6. contract only after policy allows blocking/exporting the remaining clients.

A client kill switch must be coarse, cached, authenticated, and safe when unreachable. It cannot be the sole defense for a bug in offline code. Feature flags themselves need versioned defaults; an old client that never fetches the new flag will keep its embedded behavior.

Device telemetry must be useful and private

Telemetry can reveal device identifiers, location, network provider, document names, input text, photos, and behavioral routines. Collect the minimum fields required for a decision, aggregate or bucket on device, rotate pseudonymous identities where permitted, apply retention/deletion rules, and require authorization for diagnostic escalation. Never upload content to explain a latency histogram by default.

Sampling changes evidence. The fixture samples 2% of two million active devices: 40,000 devices. At six aggregate events per sampled device-hour, ingestion receives 240,000 events/hour or 4,000/minute. That arithmetic sizes ingestion; it does not prove representativeness. Correct for cohort and inclusion probability where appropriate, preserve denominators, and keep opt-out or platform restrictions visible. Rare crashes, low-end devices, and offline failures may be underrepresented precisely because their telemetry does not arrive.

Use on-device histograms or bounded summaries for launch, local operation, sync age, bytes, energy proxies, and failures. Attach app/OS/device cohort, network mode, schema, and evidence version without raw content. Keep upload bounded and lower priority than user synchronization. A telemetry outage must not block product work.

Mobile performance budget

User promise
  operation; local/synced/completed milestone; objective; stale/offline behavior;
  conflict and failure presentation

Fleet
  supported hardware/OS/app cohorts; memory/storage/thermal/battery tails;
  accessibility; maximum offline and upgrade windows

Local state
  authority/derived role; encryption; size; operation log; schema; compaction;
  crash recovery; pending/conflicted/rejected lifecycle

Network and synchronization
  RTT/bandwidth/loss modes; payload and delta distributions; compression CPU;
  retries; operation identity; snapshot/log retention; chunk resume

Placement
  device/edge/region/origin paths; authority; freshness; fallback; residency;
  acknowledgment and deletion semantics

Resource budgets
  foreground CPU/memory/frame time; background windows; bytes by network class;
  radio/CPU/storage energy; thermal response; prefetch and telemetry limits

Versions and rollout
  capabilities; current/previous/legacy shares; expand/migrate/contract;
  offline operations; kill behavior; rollback and support floor

Evidence
  observed/modeled/simulated fields; privacy and sampling; raw reproduction;
  uncertainty; device/network tests; owner, review date, transfer limits

Test combinations, not isolated best cases: low memory plus large local state, loss during schema migration, old client plus new server, thermal pressure plus media compression, revocation while offline, regional recovery plus reconnect wave, and conflict while a photo upload resumes.

Applied work

Design multi-device offline editing. Define operation identity, local durability, base and schema version, authority, delta/snapshot retention, and policies for independent fields, concurrent titles, unsafe state, deletion, and media. Specify the exact responses for accepted, duplicate, conflicted, unauthorized, incompatible, and snapshot-required operations. Crash after local commit, server commit before acknowledgment, and conflict receipt before UI apply.

Reduce perceived latency honestly. Reproduce the 18 ms local versus 850 ms connected timeline. Name what is true at local commit and what still depends on authority. Design pending, retrying, synced, conflicted, and rejected states for visual and assistive output. Preserve user input through rejection and show bounded stale content without enabling authority-sensitive actions.

Rehearse an intermittent rollout. With 70/22/8% version cohorts, add one schema field and one new operation. Disconnect legacy devices for the migration window, rotate authorization, interrupt a 12 MiB upload after thirty-six chunks, apply thermal pressure, and constrain background execution. Verify capability negotiation, 9 MiB retransmit savings, energy/byte budgets, privacy-safe evidence, export or upgrade behavior, and the condition for contract removal.

Sources and transfer limits

• Android’s current offline-first data-layer guidance describes local/network sources, queued reads/writes, synchronization, conflict considerations, and constrained work in one platform architecture. It does not choose Fieldnote’s authority or merge semantics.
• Android’s current WorkManager guidance documents persistent scheduled work and constraints. Exact timing, quotas, and behavior are OS/version/device-specific; no periodic background deadline should be inferred.
• Apple’s current networking energy guidance explains one platform’s coalescing and background-transfer mechanisms, while battery analysis guidance identifies device/app-state measurement dimensions. The fixture’s joules are not Apple measurements.
• Apple’s current MetricKit documentation provides one privacy- and platform-governed source of field performance and diagnostic summaries. Delivery cadence and available metrics are platform-specific and do not replace application synchronization evidence.
• RFC 9111 defines HTTP cache freshness and validation semantics. Application local stores, authorization leases, offline mutations, and multi-device conflicts need additional contracts.
• Shapiro and colleagues’ primary conflict-free replicated data types report formalizes convergence conditions for CRDT families. Convergence does not supply Fieldnote’s business invariants, authorization, privacy, schema migration, or user conflict policy.

The chapter’s arithmetic is reproduced by examples/performance-engineering-system-design-handbook/part-05/edge-mobile-offline/. Values are modeled, not measurements of a platform, device, carrier, battery, or production service. A concrete decision needs supported-device distributions, real network traces, local-state and conflict populations, platform-version behavior, power measurements, privacy review, upgrade history, and interrupted rollout/recovery evidence.

Decision rule

Move work and state toward the user when the local path produces a useful, honestly labeled outcome and the system can still name authority, reconcile conflicts, protect private data, bound bytes and energy, and support old clients. When those obligations cannot be met, keep authority online and design an explicit degraded or deferred experience.

Part V has composed the book’s mechanisms across request/response, transactional, caching, streaming, analytical, search, object, real-time, inference, and edge systems. The next part changes the question from “what should this archetype do?” to “what evidence can distinguish useful work, waiting, saturation, failure, quality, and user impact?”