A network link to a factory floor drops for ninety seconds. Somewhere a cloud dashboard goes gray. The question that matters is what the machines did during those ninety seconds. If they kept running, kept measuring, kept deciding — good architecture. If they froze or went blind because the smarts lived a thousand kilometers away, someone drew the line in the wrong place. Deciding what compute belongs at the edge and what belongs in the cloud is that line, and it is mostly not about compute at all.
Latency and connectivity draw the line
Two questions settle most of it. How fast does a decision have to happen, and what happens when the network is not there. If a control loop has to react in milliseconds — trip a relay, reject a part, throttle a motor — it cannot wait for a round trip to a data center, and it never should. If the link is intermittent by nature, which every industrial and remote site eventually is, then anything safety or production critical has to survive without it. Latency and connectivity, not horsepower or fashion, are what push a given piece of logic down to the edge or up to the cloud.
Process at the edge so a blip does not blind you
The edge earns its keep by turning raw signal into decisions and evidence locally. A vibration sensor streaming full waveform to the cloud is a bandwidth bill and a single point of failure; the same sensor computing an RMS trend on the device and raising a flag when it drifts is useful whether the link is up or down. And when the link does drop, the edge buffers. It keeps a local ring of recent data, timestamps everything, and reconciles when connectivity returns, so a gap in the network becomes a gap you can backfill rather than data that never existed.
Keep the edge dumb, keep the cloud smart
The temptation is to push more and more intelligence to the device until the edge becomes a small unmaintainable cloud you cannot reach. We resist it. The edge should do a few things it can do reliably forever — read sensors, run fixed control logic, buffer, and forward — and little else, because every feature you add there is a feature you have to update in the field across thousands of units. The cloud is where the expensive, changeable thinking lives: fleet-wide models, cross-site correlation, retraining, dashboards. Dumb enough to be reliable at the edge; smart enough to be worth it in the cloud. Bandwidth and cost follow the same rule — ship decisions and summaries over the wire, not raw firehoses.
The edge should be too simple to fail and the cloud too useful to ignore. Blur that line and you get the worst of both.— Protocore · Hardware engineering
We drew exactly this line on an energy and manufacturing deployment: readers and controllers on the floor ran their loops and logged locally, indifferent to the WAN, while aggregation, analytics, and updates lived upstream. When a site lost connectivity for an afternoon, production never noticed and nothing was lost — the data simply caught up. That is the payoff of getting the split right. It is the same instinct behind the access-control readers and NFC wristbands we have taken from prototype to certified OEM hardware at volume: put the reliable, boring work where it must never fail, and keep the clever work where you can still change your mind.
Have a system to build?
Tell us the problem. We'll come back with an architecture and a plan.
Start a project