Intermittent connectivity and local fallback

Name which functions remain available locally and which require a remote service. A smaller on-device model, cached rules, or an explicit unavailable response can each be appropriate when its consequences are understood. Validate the fallback on the workload it will receive during outages, which may differ from ordinary traffic. Record the local model and preprocessing version with each result so a later server response can be reconciled without pretending the two decisions came from the same pipeline.

Cached context also has a freshness contract. Distinguish the age of data from the time since the last successful network request; a freshly downloaded response can contain old source data. Use explicit source versions and trusted time assumptions where needed. A device’s wall clock can jump, while a monotonic elapsed timer usually does not survive every reboot with the same origin. Specify how restart, clock uncertainty and expiration affect continued operation rather than silently extending validity whenever the device is offline.

Persist queued records before acknowledging a durable local submission, and define what happens when storage fills. Coalescing the latest state can be suitable for replaceable telemetry but destructive for an audit event or user action. On reconnect, bound retry traffic and reserve capacity for new arrivals. The server and client need compatible record schemas, artifact identifiers and deduplication rules. A locally successful prediction does not imply that a related remote transaction was committed or that its delayed response is still useful.

A request can reach the server and commit while its response is lost. Blind retry can then repeat a non-idempotent effect. Use a task-specific idempotency key and server-side durable outcome handling when the operation requires it; HTTP method semantics alone do not give arbitrary application actions exactly-once execution. Set an expiration or reconciliation rule for late results, and test restarts after sending but before recording acknowledgment. Backoff reduces retry pressure but does not resolve uncertainty about an earlier commit.

Exercise prolonged offline operation, flapping connections, captive portals, expired credentials, full storage, process death and clock changes. Verify the local decision policy, durable queue and eventual reconciliation together. Android’s offline-first guidance illustrates separating local and network data responsibilities, but it is architecture guidance rather than a guarantee that every model result or write synchronizes automatically. Measure recovery under a fleet reconnect burst so a server-side bottleneck does not turn a local outage into a much longer incident.

The queue instrument demonstrates net draining only. Reset, set arrival lambda to 2 and service mu to 4, predict backlog two after two Steps and zero at two seconds, then take two Steps. Continue two more Steps to see the drain. Compare a fresh Reset with both lambda at 4 and mu at 4 before two Steps: backlog stays four. It starts with four cases and models constant rates, not persistent storage, network failures, deduplication or record acknowledgment.