Designing for Disconnection and Failure

A deployment architecture should be evaluated in the state where something important is unavailable.

For cloud-dependent inference, ask what happens when:

• the network is slow;
• DNS or routing fails;
• the service is unavailable;
• authentication expires;
• bandwidth collapses.

For local inference, ask what happens when:

• device compute is overloaded;
• the model cannot load;
• storage is corrupted;
• thermal throttling increases latency;
• the update process leaves incompatible versions.

Offline is a requirement, not a marketing label

A system is not truly offline-capable just because the model file exists locally. Every dependency required for the intended function must be available without the network.

Imagine a local model that runs without internet but requires a remote configuration service before it will start. During a network outage, the model is present but the system is not operationally offline-capable.

This is why dependency mapping matters.

Failure can change the deployment decision

A system that usually has excellent connectivity may still require local fallback if the consequence of losing inference is high.

Conversely, a low-consequence application may reasonably wait for cloud service to return rather than carrying an expensive local model.

The architecture should match the consequence, not just the average network condition.

Before the lab

Predict what happens to a cloud deployment when network latency doubles and bandwidth falls. Then decide what evidence would cause you to switch to edge, hybrid, or a non-AI fallback.