IoT Edge Module Routing Under Intermittent Uplink
A manufacturing line runs an IoT Edge device on a gateway that aggregates 40 Modbus sensors. The site has a satellite uplink that drops for 20–90 minutes several times per day. Edge modules include a protocol adapter, a filtering module, and a local SQL storage module. The business requires that no sensor reading be lost during outages and that downstream cloud analytics receive readings in near-original order once connectivity returns. Currently, the filtering module sends directly to $upstream, and the team observes gaps in cloud data after each outage. The gateway has 8 GB RAM and 4 vCPUs, and modules are already near 70% memory utilization.
1. Why are readings lost during outages, and how should routes and modules change to guarantee durability?
Read the worked answer
The likely cause is that messages are routed to $upstream and the edge hub's time-to-live (TTL) expires while the uplink is down. Edge hub queues messages for offline delivery, but once TTL elapses they are dropped. With 20–90 minute outages, the default TTL is easily exceeded.
The fix is a store-and-forward design:
- Route the filtering module's output to the local storage module (a route such as
FROM /messages/modules/filter/outputs/* INTO BrokeredEndpoint("/modules/storage/inputs/input1")), so readings are persisted locally rather than only queued in memory. - The storage module (or a dedicated forwarder) reads from local storage and publishes upstream when connectivity is available, acknowledging only after successful delivery.
- Increase edge hub TTL appropriately and size the in-memory queue, but treat TTL as a safety net, not the durability mechanism - memory is constrained at 70% utilization.
Judgement: durable delivery requires persistence outside edge hub's bounded queue. Relying on a larger TTL alone risks memory exhaustion on an 8 GB gateway.
2. How should the team preserve near-original ordering in cloud analytics?
Read the worked answer
Ordering is not guaranteed end-to-end: edge hub and IoT Hub are partitioned streams, and the built-in endpoint delivers per-partition order, not global order. To approximate original order:
- Attach a monotonic sequence number and device timestamp at the adapter or filter module, before any queueing. Ordering must be reconstructed downstream from this field, not inferred from arrival time.
- Partition by device (or device group) so all messages from one sensor land on the same partition and are delivered in order within that partition.
- Use the sequence number in the storage module's replay so that after an outage, buffered readings are forwarded in sequence order.
- Make the analytics consumer order-tolerant: buffer and sort by sequence number within a window, since late arrivals after an outage will interleave with live data.
Judgement: you cannot promise strict global ordering across a partitioned, intermittently connected path. You can promise per-device ordering plus sequence-based reordering downstream, and the design should state that contract explicitly.
3. Memory is at 70% on an 8 GB gateway. What risks does adding a storage module introduce, and how would you mitigate them?
Read the worked answer
Risks:
- Memory headroom collapse. Adding a module and its buffers can push the gateway into pressure, causing module restarts or OOM kills - which would defeat durability.
- Unbounded local storage growth. During a 90-minute outage at 40 sensors, the volume may be modest, but repeated failures without pruning can fill disk. Disk exhaustion can also crash modules.
- Replay storms on reconnect. Forwarding a large backlog at full speed can overwhelm the uplink or downstream throttling.
Mitigations:
- Set resource limits on modules and monitor memory; size the storage module's cache explicitly.
- Retention and pruning policy with alerting on disk usage.
- Rate-limited replay with backoff and acknowledgment-based deletion.
- Prefer disk-backed persistence over enlarging in-memory queues, given the memory constraint.
Judgement: durability must not be achieved by consuming the headroom that keeps the gateway stable; disk-backed, pruned, rate-limited forwarding is the safer design.