A product team is designing a connected system. One engineer wants everything in the cloud because it simplifies centralized management. Another argues for edge computing because latency matters. Someone else recommends hybrid architecture because it sounds safer.
This discussion often starts at the wrong end.
Before deciding where the software should run, ask a more useful question:
What happens when part of the system stops working?
Does the machine stop? Does an alarm disappear? Does the device continue collecting data? Can an operator still make a decision? Does data wait locally and synchronize later? Or does the entire product become unavailable?
Those answers tell you far more about the right architecture than a preference for AWS, Azure, Kubernetes, gateways, or a particular database.
AWS makes a similar point in its reliability guidance. Its Well-Architected Framework recommends designing workloads to withstand component failures, defining recovery objectives, testing recovery procedures, and implementing graceful degradation rather than assuming every dependency will remain available.
What Cloud, Edge, and Hybrid Actually Mean
Start with simple definitions.
A cloud-first architecture sends most application processing and data to centralized infrastructure. Devices may collect information, but decisions, analytics, storage, dashboards, and business logic primarily depend on cloud services.
An edge architecture moves selected processing closer to where data originates. That might mean a gateway inside a factory, software running on an industrial PC, or processing directly on the device.
NIST describes edge computing in the context of moving computation closer to devices and users rather than relying entirely on remote centralized computing.
A hybrid architecture combines the two. Some functions remain local while centralized functions stay in the cloud.
For example, a machine-monitoring system might detect a dangerous operating condition locally in milliseconds, retain readings during an internet outage, and later send summarized data to the cloud for fleet analytics.
That is not hybrid architecture because hybrid is fashionable. It is hybrid because different functions have different failure and latency requirements.
Architecture rule: decide where a function must survive before deciding where it should run.
Why Failure Conditions Should Drive Architecture
Imagine an environmental monitoring system installed across 100 commercial buildings.
Sensors send measurements to a gateway. The gateway forwards them to the cloud. The dashboard displays current conditions and generates alerts.
The normal architecture diagram looks fine.
Now disconnect the internet.
What happens?
That question immediately exposes whether architecture decisions were based on operating requirements or simply on the happy path.
Internet Connectivity Failure
Ask:
How long can the site operate without internet access?
Thirty seconds?
Two hours?
Two days?
Indefinitely for selected functions?
AWS IoT Greengrass explicitly supports local processing and operation with intermittent connectivity. Its documentation describes devices responding locally while cloud infrastructure remains available for management, analytics, and durable storage.
Microsoft Azure IoT Edge follows a similar model. Microsoft documents that an IoT Edge device can continue operating during intermittent or absent internet connectivity after the required initial synchronization. Messages intended for the cloud can be stored locally and forwarded after reconnection, subject to storage capacity and configured message lifetime.
This distinction matters.
If losing internet means you temporarily lose historical dashboards, cloud-only processing might be acceptable.
If losing internet means a safety-related local alert disappears, the architecture deserves another review.
Cloud Service Failure
Internet connectivity and cloud availability are different failure conditions.
The site’s connection may be healthy while an API, database, authentication service, application service, or cloud region is unavailable.
Ask:
What functions become impossible when the cloud service cannot respond?
A reporting portal being temporarily unavailable has a different consequence from a machine being unable to execute a required local control rule.
AWS reliability guidance specifically recommends designing distributed systems to mitigate failure, including graceful degradation, fault isolation, failover, recovery automation, and testing of recovery procedures.
A system does not need to reproduce every cloud capability locally.
It needs to preserve the capabilities whose absence creates unacceptable consequences.
Gateway or Edge Failure
Moving processing to the edge does not eliminate failure.
It moves the failure boundary.
Suppose 40 sensors depend on one gateway.
Internet failure may no longer stop local processing, but gateway failure could stop all 40 devices from reporting.
Now you need to ask:
- Can devices buffer their own data?
- Can they connect through another gateway?
- How quickly can the gateway be replaced?
- Does configuration automatically restore after replacement?
- Is the local state backed up?
- Does the customer know the gateway has failed?
This is why “edge” should not automatically be treated as “reliable.”
Edge computing creates local independence, but it can also introduce hardware, storage, software-update, configuration, and maintenance responsibilities at every deployment location.
Power Failure
Power is often missing from architecture discussions because it sits outside the software diagram.
It should not.
If the site loses power, does the entire system stop?
Perhaps that is acceptable.
Perhaps the gateway requires backup power.
Perhaps devices operate from batteries while network equipment does not.
Perhaps a system must preserve its most recent state so it restarts predictably.
The architecture decision therefore extends beyond cloud versus edge. It includes the physical conditions required for each component to perform its role.
Delayed or Missing Data
Connectivity failure also creates a data question.
Suppose a gateway collects one measurement every minute from 50 sensors.
That is:
50 readings per minute × 60 minutes × 24 hours = 72,000 readings per day.
If connectivity disappears for three days, the gateway may need to retain at least 216,000 readings, before considering metadata, retries, logs, or overhead.
That immediately turns “support offline mode” into a storage requirement.
Protocols can help with delivery behavior, but they do not remove the architectural decision.
For example, the OASIS MQTT 5.0 standard defines three Quality of Service levels: QoS 0 provides at-most-once delivery, QoS 1 provides at-least-once delivery, and QoS 2 provides exactly-once delivery between MQTT sender and receiver at the protocol level. Higher delivery assurance introduces additional protocol handling.
Choosing MQTT QoS is therefore part of the reliability design, not a substitute for it.
How to Turn Failure Conditions Into Architecture Requirements
A useful architecture review can begin with four questions.
1. Define the Required Response Time
Ask how quickly each action must happen.
| Function | Example Requirement | Likely Location |
|---|---|---|
| Emergency machine shutdown | 20 ms | Device / local controller |
| Local operator warning | 500 ms | Edge / local |
| Building alert | 5 seconds | Edge or cloud |
| Dashboard refresh | 30 seconds | Cloud acceptable |
| Daily fleet report | 24 hours | Cloud |
These are illustrative requirements, not universal thresholds. The correct numbers must come from the product, operational, and safety requirements.
The important point is that different functions inside the same product may belong in different places.
2. Define Offline Requirements
Do not write:
“System should work offline.”
Write:
“If WAN connectivity is unavailable for 24 hours, devices must continue collecting measurements, local alarms must remain operational, at least 24 hours of telemetry must be retained, and queued records must synchronize after reconnection.”
Now engineers can design something testable.
Microsoft’s IoT Edge documentation provides a practical example of this model. It supports local message storage and forwarding after reconnection, while making clear that retention ultimately depends on configuration and available disk space.
3. Define Acceptable Data Loss
Not every measurement has equal value.
Losing one temperature sample in a stream of thousands may have limited consequence.
Losing the event showing that a safety threshold was crossed could be much more serious.
Classify data accordingly:
Critical: must persist reliably.
Operational: limited loss may be acceptable.
Analytical: aggregation may be sufficient.
Diagnostic: retain when useful and storage permits.
This classification can influence buffering, persistence, transmission priority, QoS, database design, and synchronization logic.
4. Define Recovery Behavior
Many systems describe failure but not recovery.
That is a mistake.
Suppose connectivity returns after six hours.
Now ask:
- Does historical data upload automatically?
- Does current data receive priority over backlog?
- How are duplicate events handled?
- What happens if configuration changed while the device was offline?
- How does the dashboard distinguish delayed data from live data?
- Who is notified that the device recovered?
Azure IoT Edge, for example, documents synchronization of locally stored messages after connectivity returns and reconciliation of device and module state.
Recovery is part of the architecture, not an operations problem to solve later.
Cloud vs Edge vs Hybrid: The Trade-Offs
There is no universally superior option.
| Architecture | Strength | Main Trade-Off |
|---|---|---|
| Cloud | Central management and scalable shared services | Connectivity dependency |
| Edge | Fast local processing and offline capability | Distributed operational complexity |
| Hybrid | Selective local resilience plus centralized services | More synchronization and state-management complexity |
Cloud-first designs can reduce the amount of software maintained at individual sites.
Edge designs can reduce dependency on WAN connectivity and shorten local response paths.
Hybrid systems can provide both, but they introduce synchronization questions that pure cloud or pure local systems may avoid.
That is why hybrid should not automatically be the default.
Use it when requirements justify the additional moving parts.
If you are already evaluating whether your IoT product can survive outside a controlled pilot, also review The IoT Architecture Is Only Half the Product and Seven Questions I Ask Before Approving an IoT Pilot. The architecture has to work together with provisioning, diagnostics, support, updates, and field operations.
CTA: Review the architecture before adding another component. Map what must continue working when each dependency disappears.
Example: An Industrial Monitoring System
Consider a vibration-monitoring system for factory equipment.
The first design sends raw vibration data continuously to the cloud, analyzes it there, and returns alerts.
Now apply the failure test.
If internet access disappears for four hours, should monitoring stop?
Probably not if the purpose of the system is to detect conditions that require an immediate local response.
A different architecture might therefore:
- acquire sensor data locally,
- calculate selected features at the edge,
- evaluate urgent rules locally,
- store measurements while disconnected,
- send summaries and events to the cloud,
- use the cloud for fleet analytics, historical comparison, user management, and reporting.
This is a hybrid architecture.
But the important conclusion is not “hybrid is better.”
The conclusion is:
The required behavior during connectivity failure created the hybrid architecture.
Change the requirement and the architecture may change with it.
A weather sensor used only to populate tomorrow’s research dataset could reasonably tolerate delayed transmission.
A control system responsible for an immediate local action may not.
Same technologies. Different failure consequences. Different architecture.
What to Do Next
Before approving a cloud, edge, or hybrid architecture, run a three-step review.
Step 1: Write the Failure Matrix
List the important dependencies:
- Device
- Sensor
- Local network
- Gateway
- Internet
- Cloud API
- Database
- Authentication
- Power
- External integration
For each one, write what happens when it becomes unavailable.
Step 2: Map Functions to Their Required Location
For every major function, document:
Response time
Offline requirement
Data-location requirement
Failure consequence
Recovery behavior
Component owner
A one-page assessment is usually more valuable at this stage than another architecture diagram.
Step 3: Test the Failure Paths
Do not only demonstrate that the system works.
Disconnect the network.
Restart the gateway.
Fill the local storage.
Delay messages.
Make the cloud API unavailable.
Restore the connection.
Then observe whether the system behaves as the architecture document promised.
AWS explicitly recommends testing recovery procedures and conducting resiliency exercises rather than relying solely on assumptions about failure handling.
That is the final test of architecture quality.
Not whether the diagram looks elegant.
Whether the system behaves predictably when part of that diagram disappears.
Limitations and Safety Considerations
The framework above is intended for general architecture planning. Systems involving industrial control, medical devices, automotive functions, energy infrastructure, life safety, or regulated environments may require formal hazard analysis, redundancy, certification, deterministic controls, or industry-specific standards.
Cloud or edge software should not be assumed to provide a safety function simply because it continues running offline.
For safety-critical systems, architecture decisions should be reviewed against the relevant engineering, cybersecurity, regulatory, and functional-safety requirements.
FAQ
What is the difference between cloud, edge, and hybrid architecture?
Cloud architecture performs most processing in centralized cloud infrastructure. Edge architecture places selected processing near devices or data sources. Hybrid architecture combines local processing with centralized cloud services.
When should I use edge computing instead of cloud computing?
Edge computing becomes useful when functions require low local response time, operation during internet outages, reduced data transmission, local data processing, or continued operation independent of remote services. The decision should be based on specific requirements rather than a general preference for edge technology.
Is hybrid architecture better than cloud architecture?
Not automatically. Hybrid architecture can provide local resilience while retaining centralized cloud capabilities, but it also creates additional synchronization, deployment, update, monitoring, and state-management complexity. Use hybrid architecture when those costs are justified by the requirements.
Can IoT devices continue working without internet access?
They can if the architecture is designed for it. Platforms such as AWS IoT Greengrass and Azure IoT Edge support local processing during intermittent connectivity. Azure IoT Edge can also retain upstream messages locally and forward them after connectivity returns, subject to configuration and available storage.
What should an architecture failure assessment include?
At minimum, assess internet loss, cloud-service failure, gateway failure, device failure, power failure, storage exhaustion, and delayed data. For each condition, document required system behavior, acceptable downtime or data loss, recovery behavior, and ownership.
How do I choose between cloud, edge, and hybrid for IoT?
Start by defining response-time requirements, offline duration, data-location constraints, acceptable data loss, failure consequences, and recovery behavior for each function. Then place each function in the cloud, edge, or device according to those requirements.
Leave a Reply