Edge & Fog Computing · Study deck

Operational Failure Modes

A gateway reboots. Can local control continue? Which decision, buffer, clock, and recovery path still has an owner?

Edge Eddie is your guide for this deck.

The existing cited IoT resilience decision flow routes connectivity loss, sensor anomalies, and component crashes to named recovery actions.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Identify eight practical failure modes in edge and fog computing deployments.
  • Explain why retry storms, missing local buffers, and weak failover damage production systems.
  • Design retry, buffering, clock, and management controls that preserve local service during disruption.
  • Write a pitfall review record that captures symptoms, owner, mitigation, and verification evidence.
iotclass.org

Major section

In 60 Seconds

Local operation is safe only when degraded behavior and recovery order are explicit.

  • A gateway means the boundary system that joins local devices to another network or service.
  • Edge and fog deployments fail when teams treat local infrastructure as a small cloud instead of a distributed system with physical constraints.
Real photograph of rotary potentiometer
Real photograph of rotary potentiometer
iotclass.org

Major section

Why Edge-Fog Pitfalls Are Different

Cloud-only systems can often centralize failure handling.

  • Edge and fog systems cannot.
  • A device may be in a vehicle, factory cell, clinic, farm field, building closet, or roadside cabinet.
  • The system may need to keep acting while the cloud link is down, while a fog node is rebooting, or while a certificate update is rolling out across only part of the fleet.
iotclass.org

Major section

Pitfall Map

The final Decision Ownership and Verification Evidence boxes require an owner plus logs, traces, screenshots, or measurements for each failure path.

  • It should also name the owner, the mitigation, and the test evidence.
Edge-fog pitfall map.
Edge-fog pitfall map.
iotclass.org

Major section

Failure Contract Drill

For one critical workload, name the degraded states before the design review ends: slow, unreachable, stale, overloaded, compromised, and updating.

  • A named failure mode can become a bounded design.
  • An unnamed failure mode becomes an outage.
  • Paper ownership is not enough.
  • Which tier can command actuators, reject unsafe states, or make local decisions without waiting upstream.
iotclass.org

Major section

Pitfall 2: Retry Logic Creates a Recovery Storm

Retries are necessary, but identical retry schedules can create a second outage.

  • If 10,000 devices reconnect at the same deterministic intervals, a fog broker that just recovered can be overloaded again by the recovery traffic.
  • Full jitter means the retry is sampled from the whole current backoff window.
  • Equal jitter keeps a minimum delay and samples from only the upper half of the window.

Key terms

Either
Either is better than no jitter, but a large fleet usually needs maximum spreading during mass recovery.
iotclass.org

Major section

Pitfall 3: The Buffer Preserves the Wrong Data

On the left, raw sample cards crowd the bin while the alert is pushed out.

  • On the right, the smaller store keeps alert and failure cards ahead of routine samples.
  • The drawing makes the rule concrete: a local buffer needs a retention policy, or a long disconnection can erase what operators most need.

Why it matters

A buffer policy should be judged inside the wider failure response, because retaining the wrong records can undermine recovery even when storage itself works. @fig-edge-fog-resilience-loop shows where prioritisation and quarantine belong.

Designing for failure: an IoT system detects connectivity loss, sensor anomalies, or component crashes and routes each to a graceful recovery action such as edge fallback or local caching.
Designing for failure: an IoT system detects connectivity loss, sensor anomalies, or component crashes and routes each to a graceful recovery action such as edge fallback or local caching.
iotclass.org

Major section

Pitfall 4: Clock Discipline Is Treated as Optional

Edge and fog logs are useful only when events can be ordered.

  • Cheap oscillators drift, devices reboot without network time, and gateways may receive delayed batches after connectivity returns.
  • Whether the device clock was synchronized, estimated, stale, or unknown.
  • A monotonic counter that helps order records when wall-clock time is suspect.
iotclass.org

Major section

Pitfall 5: The Fog Layer Becomes a Hidden Single Point of Failure

Compare failover interruption with the workload's physical deadline; define edge fallback or active-site state-conflict rules when a pause is unsafe.

  • Compare failover interruption with the physical deadline.A backup boot test cannot establish whether the workload can tolerate the pause.
  • Use an edge fallback when the process cannot wait.Immediate protection needs an owner near the physical boundary.
  • Define state-conflict rules for active-active service.More than one serving node needs an explicit way to resolve conflicting state.

Key terms

Good when failover pause
Good when failover pause is not acceptable, but state conflict rules must be explicit.
iotclass.org

Major section

Pitfall 6: Fleet Management Is Added After Deployment

Small pilots can be managed manually.

  • Production fleets cannot.
  • Once devices are distributed, each update, credential rotation, configuration change, and rollback becomes an operational path.
  • Identity: Each device, gateway, and service has a unique identity and a documented owner.
  • Health: Each node reports version, configuration hash, uptime, resource pressure, and last successful sync.
iotclass.org

Deck summary

Key takeaways

Local operation is safe only when degraded behavior and recovery order are explicit.

  • Cloud-only systems can often centralize failure handling.
  • The final Decision Ownership and Verification Evidence boxes require an owner plus logs, traces, screenshots, or measurements for each failure path.
  • For one critical workload, name the degraded states before the design review ends: slow, unreachable, stale, overloaded, compromised, and updating.
  • Retries are necessary, but identical retry schedules can create a second outage.
iotclass.org

Retrieval practice

Recall check 1 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q1An architecture picture shows edge, fog, and cloud boxes. What makes it an operating contract?

ANamed owners and tested data, control, management and failure paths across tiers
BDecorative arrows connecting tiers without authority, traffic or failure contracts
CCloud-only happy-path demonstration without testing local failure behavior
DBoard model names alone without recovery or management responsibilities
Show answer

Answer: A The diagram needs behavior and evidence for stressed paths.

iotclass.org

Retrieval practice

Recall check 2 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q2A cold-chain gateway normally approves compressor commands, but truck sensors must protect cargo while the gateway is rebooting. What is the safest ownership pattern?

ALet the cloud approve every compressor command because its history is complete, even if WAN or gateway reboot delays the response
BGive the edge controller a bounded local protection rule and send evidence to the gateway when it returns
CDisable all local compressor action until the gateway finishes rebooting, even if cargo temperature crosses the safe bound
DStore each compressor command and replay it later as if delayed physical-control commands were still current
Show answer

Answer: B The edge controller can own the immediate safe response, while the fog gateway and cloud still receive evidence for review and fleet learning.

iotclass.org

Retrieval practice

Recall check 3 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q3A production cell requires a local reject decision before a part leaves the inspection station. The fog node can fail over to a standby node in 20 seconds. What should the review flag?

AThe failover is always adequate because a local standby is present, even though the physical line needs decisions immediately
BThe design needs active-active processing or an edge-side fallback rule because the 20-second gap can miss parts
CThe cloud should replay missing reject decisions after the line resumes, even when the affected parts have already moved on
DThe issue is only dashboard visibility, not the continuity of the local control path for parts leaving the station
Show answer

Answer: B For an immediate reject decision, a 20-second service gap is a process failure unless local fallback or near-zero failover is provided.

iotclass.org

Retrieval practice

Recall check 4 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q4What lets another fog node resume shared filtering, routing or control after failure?

AEdge Fallback
BCloud Reconciliation
CFog Failover
DManagement Channel
Show answer

Answer: C Another gateway or fog node must resume shared filtering, routing, or control.

iotclass.org

Retrieval practice

Recall check 5 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q5A review finds that every device reports only to the cloud dashboard. There is no local queue-depth metric, no last-sync timestamp, and no retry-state report from the fog node. Which pitfall is most likely?

AObservability ends at the cloud dashboard, hiding local fog failure state
BOversized buffer capacity, even though no queue-depth metric is available
CThe edge clock is too accurate, despite no local timing or retry report
DCloud user count is too high, despite missing fog-node health signals
Show answer

Answer: A The system cannot diagnose local failure modes if local health and retry state are visible only after successful cloud upload.

iotclass.org

Retrieval practice

Recall check 6 of 6

Edge Eddie says: answer from memory, then check your reasoning.

Q6After an outage, a gateway replays buffered readings out of arrival order. What clock control helps preserve the real sequence?

AKeep event and ingest times, sync status and a sequence marker for replay checks.
BSort replay by cloud arrival time alone, treating upload order as the true physical event order.
CAssume edge clocks stayed accurate throughout outage and buffered replay.
DDelete old buffered readings before comparing timestamps and event order.
Show answer

Answer: A Separate times and clock status expose delay and drift during replay.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. A · The diagram needs behavior and evidence for stressed paths.
  2. B · The edge controller can own the immediate safe response, while the fog gateway and cloud still receive evidence for review and fleet learning.
  3. B · For an immediate reject decision, a 20-second service gap is a process failure unless local fallback or near-zero failover is provided.
  4. C · Another gateway or fog node must resume shared filtering, routing, or control.
iotclass.org
With the first answer frame visible, connect ownership to tested paths. Device protection continues through gateway reboot only with a bounded local rule. A twenty-second fog gap can miss a physical reject. Put each recovery control at the boundary it protects.

Print reference

Answers 2 of 2

Answer key.

  1. A · The system cannot diagnose local failure modes if local health and retry state are visible only after successful cloud upload.
  2. A · Separate times and clock status expose delay and drift during replay.
iotclass.org
The final two answers concern visibility and time. Keep local queue, sync, and retry state observable when cloud upload fails. During replay, compare event and arrival times with clock status and a sequence marker. A late record must not look like a new physical event.