The edge-to-cloud architecture decision

The sorting exercise

Some things must continue through a disconnection: production execution, safety systems, quality holds, anything that stops a line. Others can wait: analytics, reporting, most integration, anything whose value is measured in days rather than minutes.

Sorting workloads into those two categories, explicitly and with operations present, is the architectural decision. It determines what runs locally, what runs in the cloud, and what the store-and-forward path between them has to guarantee.

Done by IT alone, this exercise reliably places things in the wrong category, because the question of what genuinely stops a line is operational knowledge rather than technical.

The reconnection failure

This is the part that produces production incidents months after go-live.

The link returns after an outage. Several hours of buffered messages flow into the cloud. Something double-counts, or arrives out of order, or overwrites a value that was already correct. Nobody notices, because everything appears to be working. The discovery comes weeks later when a monthly report disagrees with the floor, by which point nobody can reconstruct which period was affected.

The design response is idempotent message handling with a stable deduplication key, a defined window for accepting late arrival, and a quarantine for anything outside it. And then deliberate testing: disconnect for a realistic period, let the buffer fill, reconnect, and verify counts reconcile exactly. Then do it again with deliberately out-of-order delivery.

• A deduplication key stable across retransmission — device, sequence and event timestamp
• Deduplication applied at ingestion rather than downstream
• A defined late-arrival window with a monitored quarantine beyond it
• Buffer depth alerting, because silent accumulation is the dangerous failure
• Reconnection tested deliberately, including with out-of-order delivery

The boundary worth stating

Reading machine data to inform planning, costing and analytics is straightforward and valuable. Writing back to anything that controls a machine is a different risk class entirely.

We treat that boundary as explicit and written down, and we are deliberately conservative about it. Any proposal that quietly crosses it deserves a direct question about who has assessed the safety implications and under what standard.

This is not a technical limitation. It is a position about where a technology consultancy's competence ends and a controls engineering discipline begins, and being clear about it is part of what a client is buying.