Edge Computing for IoT: When to Process Data on the Device

The cloud is an excellent place to store years of telemetry, compare thousands of devices, train machine-learning models, and serve dashboards.

It is not always the best place to decide whether a motor must stop during the next 20 milliseconds.

This difference is the reason edge computing matters in IoT.

Instead of treating every sensor as a pipe into a remote data center, an edge architecture asks:

What must happen here?

What can happen nearby?

What should happen centrally?

A useful architecture may therefore look like:

sensor
  ↓
local filtering
  ↓
local event decision
  ↓
gateway aggregation
  ↓
selected telemetry
  ↓
cloud storage + fleet analytics

1. Understand what “the edge” actually means

“Edge” does not identify one specific type of computer.

Several layers may exist between a sensor and the cloud.

On-device processing

sensor
+
microcontroller
+
local firmware

Examples:

• Threshold checking.
• Digital filtering.
• Debouncing.
• Feature extraction.
• Small ML inference.
• Local actuator control.

Edge gateway

many sensors
    ↓
local gateway
    ↓
Internet

The gateway may have:

• More CPU.
• More RAM.
• Persistent storage.
• Ethernet or cellular backhaul.
• Container or service runtime.

Cloud

Central infrastructure can provide:

• Long-term storage.
• Fleet management.
• Cross-site analytics.
• Model training.
• Historical dashboards.
• Large-scale search.

Hybrid is normal

Many useful systems intentionally use all three layers.

2. Split workloads between device, gateway, and cloud

IoT edge, gateway, and cloud architecture (diagram)

The architecture should follow workload constraints rather than ideology.

3. Process locally when latency is critical

Cloud processing adds a path:

sensor
  ↓
local network
  ↓
Internet
  ↓
cloud
  ↓
Internet
  ↓
controller

That path can introduce:

• Network latency.
• Routing variability.
• Queueing.
• Cloud-service latency.
• Temporary disconnection.

Local control loop

A local system can instead use:

sensor
  ↓
local decision
  ↓
actuator

This is a better fit when the response must remain predictable without depending on an external network.

Examples

• Emergency machine stop.
• Motor protection.
• Local thermostat control.
• Door access logic.
• Collision or proximity warning.
• Fast anomaly detection.

Separate local safety from cloud visibility

For example:

temperature > safety threshold
       ↓
local controller stops heater
       ↓
event uploaded to cloud
for audit + dashboard

The cloud observes the action but is not required to make the immediate decision.

4. Keep essential functions working offline

Internet connections fail.

An IoT system should explicitly decide what happens when:

DNS fails
cellular disappears
router restarts
cloud endpoint unavailable
certificate renewal service unreachable

Classify functionality

Separate:

must work offline

should work offline

cloud-only feature

Example smart-building controller

Must work offline:

temperature control
local schedules
safety limits

Can wait:

historical dashboard upload
usage analytics
fleet reports

Buffer telemetry locally

sensor readings
      ↓
local queue
      X Internet unavailable

later:

connection restored
      ↓
upload backlog

Bound the buffer

Local storage is finite.

Define:

• Maximum retained duration.
• Maximum bytes.
• Eviction policy.
• Priority data.
• Behavior when storage fills.

A gateway that stores everything forever will eventually become a full disk.

5. Reduce bandwidth by filtering near the source

Edge filtering and data reduction flow (diagram)

Some sensors generate far more raw data than the cloud actually needs.

Example vibration sensor

Imagine:

5,000 samples / second

2 bytes / sample

10,000 bytes / second

Per day:

864 MB
before protocol overhead

Most of those samples may represent normal operation.

Process locally

raw vibration
     ↓
filter
     ↓
feature extraction
     ↓
RMS + peak + spectral features
     ↓
anomaly decision
     ↓
small summary uploaded

Upload interesting windows

A useful compromise:

normal:
summary every minute

anomaly:
summary
+
10 seconds of raw waveform

This preserves detailed evidence around unusual events without streaming every raw sample continuously.

Aggregation reduces network and storage cost

Instead of sending:

60 temperature samples
per minute

the edge might send:

{
  "min": 21.8,
  "max": 22.4,
  "avg": 22.1,
  "count": 60
}

only when that loss of detail remains acceptable for the application.

6. Use edge processing to minimize sensitive data movement

Data that never leaves the site has a different exposure profile from data uploaded to centralized storage.

Example camera

Instead of:

continuous video
    ↓
cloud

an edge system may perform:

camera
  ↓
local detection
  ↓
person count:
3

raw video:
not uploaded

Data minimization

Edge processing can help convert:

sensitive raw data

into:

less-sensitive derived result

when the application genuinely does not need the source data centrally.

Privacy is not automatic

Running locally does not mean the data is automatically secure.

The device may still need:

• Encrypted storage.
• Access controls.
• Secure deletion.
• Protected debug interfaces.
• Audit logging.

Keep only what is necessary

If raw data exists only to compute a short-lived feature:

capture
  ↓
process
  ↓
derive result
  ↓
discard raw input

may be preferable to indefinite local or cloud retention.

7. Respect CPU, memory, storage, and power limits

Moving work onto a device is not free.

CPU

Ask:

How many operations
must complete per sample?

A microcontroller handling:

sensor acquisition
radio protocol
encryption
control loop

may not have enough spare CPU for expensive analytics.

RAM

Algorithms may need:

• Sample windows.
• Model tensors.
• Intermediate buffers.
• Network buffers.

An algorithm that fits comfortably on a laptop may not fit a 256 KB microcontroller.

Flash

Local processing adds:

code
model
configuration
temporary data
logs

while firmware-update strategies may also require an additional image slot.

Energy

Additional CPU activity consumes energy.

But local processing can also save energy when it prevents expensive radio transmissions.

Compare:

energy to process locally

vs

energy to transmit raw data

Thermal limits

A fanless edge computer in:

sealed outdoor enclosure
+
summer sun

may throttle or fail even if its benchmark performance looked sufficient in the laboratory.

8. Decide where machine-learning inference belongs

Edge AI normally means running inference near the data source.

On-device inference

Good fit when:

• The model is small enough.
• Latency must be low.
• Raw data should remain local.
• Connectivity cannot be assumed.

Examples:

wake-word detection

simple acoustic classification

motion classification

equipment anomaly score

Gateway inference

A gateway can run larger models:

camera / sensor
      ↓
local gateway
      ↓
GPU / accelerator / CPU
      ↓
inference result

This can combine data from several local devices.

Cloud inference

Cloud processing remains attractive when:

• The model is large.
• Compute demand is bursty.
• Centralized model deployment is valuable.
• Network latency is acceptable.

Training usually remains centralized

A common architecture is:

cloud:
train model
      ↓
validate
      ↓
package optimized model
      ↓
deploy to edge
      ↓
local inference

Model updates become firmware-like operations

Track:

• Model version.
• Runtime compatibility.
• Integrity.
• Rollback.
• Performance.
• Accuracy.

9. Use gateways when individual devices are too constrained

A local gateway creates a useful middle layer.

Protocol translation

BLE sensors
     ↓
gateway
     ↓
MQTT / HTTPS
     ↓
cloud

Aggregation

sensor A ─┐
sensor B ─┼→ gateway → site summary
sensor C ─┘

Offline buffering

The gateway can preserve telemetry while the WAN is unavailable.

Local coordination

Devices can exchange information locally:

occupancy sensor
      ↓
gateway rule
      ↓
lighting controller

without every event making a cloud round trip.

More resources

A gateway can support:

• Containers.
• Databases.
• Local message brokers.
• ML runtimes.
• Protocol adapters.

But the gateway becomes infrastructure

You now own:

operating system
storage
software updates
credentials
monitoring
backup / recovery
hardware replacement

Do not introduce a gateway merely because “edge computing” sounds sophisticated.

10. Keep cloud processing where centralization helps

Edge computing does not remove the advantages of centralized systems.

Long-term history

The cloud is well suited to storing:

months
years
fleet-wide historical telemetry

Cross-device analytics

Questions such as:

Which 500 pumps show
the highest vibration trend
across all sites?

naturally belong in a centralized analytical system.

Model training

Training can require:

• Large datasets.
• GPUs.
• Experiment tracking.
• Repeated evaluation.

Fleet management

Central systems can track:

device inventory
firmware versions
model versions
configuration
certificates
last seen
update state

Heavy queries

Do not make an embedded gateway answer a multi-year analytical query if the cloud database already exists for that purpose.

11. Define failure, buffering, and synchronization behavior

Hybrid systems can temporarily contain conflicting state.

Example

cloud desired mode:
AUTO

gateway cached mode:
MANUAL

device current mode:
MANUAL

After connectivity returns, which value wins?

Define authority

Decide which system owns:

• Configuration.
• Current physical state.
• Historical telemetry.
• Control commands.
• User policy.

Separate desired and reported state

desired:
cloud says device should be ON

reported:
device says it is OFF

This is more informative than overwriting one value with the other.

Attach timestamps and versions

{
  "config_version": 42,
  "updated_at": "...",
  "mode": "AUTO"
}

Handle replay safely

An edge queue may reconnect and upload:

10,000 historical events

The backend must distinguish them from current live state.

Commands need expiration

A command such as:

open valve for maintenance

may be unsafe to execute six hours after it was issued.

Include:

command_id
issued_at
expires_at

12. Treat edge software as production infrastructure

Moving computation from the cloud onto gateways creates more computers to secure.

Unique identity

Each edge gateway should have a distinct production identity.

Authenticated updates

Update:

• Operating system.
• Container runtime.
• Edge applications.
• ML models.
• Certificates.

Least privilege

A temperature-processing module should not need:

root access
+
firmware-signing keys
+
unrestricted cloud administration

Protect local storage

Gateways may contain:

• Buffered telemetry.
• Credentials.
• Configuration.
• Models.
• User data.

Assume physical access may happen

Edge computers often live in:

factory cabinets
retail sites
vehicles
remote buildings
outdoor enclosures

Physical location should be part of the threat model.

Monitor software versions

Fleet management should answer:

Which gateways run
vulnerable software?

Which failed an update?

Which certificate expires soon?

13. A practical edge-processing decision framework

Device vs gateway vs cloud decision tree (diagram)

Question 1: must the decision happen immediately?

If yes:

prefer device or local gateway

Question 2: must it work without Internet?

If yes:

keep required logic local

Question 3: is raw data much larger than useful output?

If yes:

filter
aggregate
extract features
locally

Question 4: is raw data sensitive?

Consider deriving the necessary result locally and sending only the minimum data required upstream.

Question 5: does the workload fit the device?

Check:

CPU
RAM
flash
energy
thermal budget

If not, move the workload to a gateway.

Question 6: does the workload require several local devices?

A gateway often fits:

sensor A
sensor B
sensor C
   ↓
shared local decision

Question 7: does the workload need fleet-wide context?

Use cloud processing for:

cross-site comparison
long-term analytics
global optimization
model training

Question 8: can the edge be maintained?

If you cannot reliably:

update
monitor
secure
recover
inventory

a complex gateway fleet, avoid unnecessary edge complexity.

Most answers are hybrid

DEVICE
fast local decision

GATEWAY
aggregation + buffering

CLOUD
history + fleet analytics

14. Copy/paste edge-computing checklist

IoT edge-computing checklist

Workload
- Define the computation.
- Define input data.
- Define output data.
- Define required latency.
- Define expected data rate.
- Define device count.
- Define processing frequency.
- Define state required by the algorithm.
- Define storage requirement.
- Define whether the result controls physical equipment.

Placement
- Consider on-device processing.
- Consider gateway processing.
- Consider cloud processing.
- Consider hybrid processing.
- Assign each workload explicitly.
- Document why each workload is placed there.

Latency
- Define maximum response time.
- Measure sensor acquisition time.
- Measure local processing time.
- Measure gateway latency.
- Measure network latency.
- Measure cloud processing latency.
- Include worst-case network delay.
- Keep safety-critical loops local where appropriate.

Offline operation
- Define expected Internet availability.
- Define maximum offline duration.
- Identify functions that must continue offline.
- Identify functions that may degrade offline.
- Identify cloud-only functions.
- Test complete WAN outage.
- Test DNS outage.
- Test gateway reconnect.
- Test cloud-service outage.

Local buffering
- Define buffer capacity.
- Define retention time.
- Define maximum bytes.
- Define eviction policy.
- Prioritize critical events.
- Protect storage from corruption.
- Monitor free disk.
- Test full-storage behavior.
- Upload backlog after reconnect.
- Preserve original timestamps.

Bandwidth
- Calculate raw data rate.
- Calculate daily data volume.
- Calculate monthly data volume.
- Include protocol overhead.
- Include retries.
- Include diagnostic traffic.
- Compare raw upload with local filtering.
- Measure actual network use.
- Estimate cellular or metered-network cost where relevant.

Filtering
- Remove noise locally where appropriate.
- Drop redundant measurements only when acceptable.
- Preserve enough diagnostic information.
- Version filtering logic.
- Test edge cases.
- Avoid silently hiding sensor failures.

Aggregation
- Calculate min.
- Calculate max.
- Calculate average.
- Calculate count.
- Calculate standard deviation where useful.
- Preserve timestamps.
- Define aggregation windows.
- Handle missing samples.
- Handle late samples.

Event detection
- Define threshold.
- Define hysteresis.
- Define minimum duration.
- Define recovery condition.
- Preserve event timestamp.
- Preserve useful context.
- Upload diagnostic window around important events where useful.

Raw data
- Decide whether raw data is required centrally.
- Decide how long raw data remains locally.
- Define event-triggered raw upload.
- Compress where useful.
- Protect sensitive raw data.
- Avoid indefinite storage without purpose.

Privacy
- Identify sensitive input.
- Minimize data collection.
- Process sensitive data locally where it satisfies the requirement.
- Upload only necessary derived values.
- Define local retention.
- Define secure deletion.
- Encrypt sensitive storage.
- Restrict local access.

CPU
- Measure processor utilization.
- Measure worst-case processing time.
- Avoid blocking critical control tasks.
- Test peak sensor input.
- Reserve capacity for firmware updates and communications.
- Profile algorithms on final hardware.
- Avoid choosing models from desktop benchmarks alone.

Memory
- Calculate code memory.
- Calculate stack.
- Calculate heap.
- Calculate sensor buffers.
- Calculate network buffers.
- Calculate ML tensor memory.
- Test fragmentation where relevant.
- Keep recovery margin.

Storage
- Calculate firmware size.
- Calculate model size.
- Calculate local database size.
- Calculate telemetry queue.
- Calculate log growth.
- Preserve update slot where required.
- Monitor storage wear.
- Bound logs.
- Handle full disk.

Power
- Measure local processing energy.
- Measure radio energy.
- Compare processing vs transmission energy.
- Include wake-up time.
- Include accelerator power.
- Include gateway idle power.
- Consider battery-operated edge devices carefully.
- Measure real workloads.

Thermal
- Define operating temperature.
- Test sealed enclosure.
- Test full CPU load.
- Test accelerator load.
- Test summer ambient conditions.
- Monitor throttling.
- Provide thermal margin.
- Avoid assuming laboratory cooling.

On-device processing
- Use for very low-latency decisions.
- Use for simple filtering.
- Use for local sensor fusion.
- Use for immediate safety logic where appropriate.
- Use for privacy-preserving feature extraction.
- Keep algorithms within hardware constraints.
- Provide secure firmware update path.

Gateway processing
- Use when many sensors need coordination.
- Use when devices are resource constrained.
- Use for protocol translation.
- Use for local buffering.
- Use for site-level analytics.
- Use for larger ML inference.
- Use when WAN connectivity is intermittent.
- Treat gateway as managed infrastructure.

Cloud processing
- Use for long-term storage.
- Use for fleet-wide analytics.
- Use for cross-site queries.
- Use for large model training.
- Use for centralized management.
- Use for heavy historical processing.
- Use for workloads that tolerate network latency.

Hybrid architecture
- Keep fast control local.
- Keep offline behavior local.
- Aggregate at gateway.
- Upload selected telemetry.
- Store long-term history centrally.
- Train models centrally where practical.
- Deploy inference model to edge.
- Synchronize configuration deliberately.

Edge AI
- Define model purpose.
- Measure model size.
- Measure inference latency.
- Measure RAM usage.
- Measure energy per inference.
- Measure accelerator utilization.
- Measure accuracy on edge hardware.
- Quantize only after validating accuracy.
- Version model artifacts.
- Authenticate model updates.
- Support rollback.

Model lifecycle
- Track model version.
- Track runtime version.
- Track input schema.
- Track training data version where appropriate.
- Validate before deployment.
- Stage rollout.
- Monitor inference quality.
- Roll back defective model.
- Remove obsolete models.

Device data
- Preserve observation timestamp.
- Preserve device identity.
- Preserve sequence number where useful.
- Distinguish raw from derived values.
- Version derived features.
- Include algorithm or model version where needed.

Gateway data
- Identify source device.
- Preserve original timestamp.
- Preserve local receive time.
- Preserve upload time.
- Avoid rewriting history accidentally.
- Deduplicate reconnect uploads.
- Handle out-of-order events.

State
- Define authoritative configuration source.
- Define reported physical state.
- Separate desired state from reported state.
- Version configuration.
- Timestamp changes.
- Define conflict resolution.
- Test offline configuration changes.
- Test reconnect reconciliation.

Commands
- Give commands unique IDs.
- Include issued_at.
- Include expires_at.
- Avoid executing stale commands.
- Make processing idempotent where appropriate.
- Record outcome.
- Separate local safety overrides.
- Define offline command policy.

Failure handling
- Define device failure.
- Define gateway failure.
- Define network failure.
- Define cloud failure.
- Define storage failure.
- Define algorithm failure.
- Define model failure.
- Define sensor failure.
- Test each scenario.

Fail-safe behavior
- Define safe physical state.
- Avoid depending on cloud for emergency stop where local control is required.
- Define behavior when input is invalid.
- Define behavior when model confidence is low.
- Define behavior when gateway disappears.
- Define watchdog behavior.

Synchronization
- Define source of truth.
- Use configuration versions.
- Use timestamps.
- Use idempotent updates.
- Handle duplicate messages.
- Handle delayed messages.
- Handle conflicting state.
- Test long offline periods.

Replay
- Preserve event time.
- Distinguish historical backlog from live state.
- Avoid duplicate side effects.
- Bound replay rate.
- Protect cloud ingestion from reconnect storms.
- Monitor backlog progress.

Security
- Give each gateway unique identity.
- Authenticate devices.
- Authenticate cloud endpoints.
- Use TLS where appropriate.
- Validate certificates.
- Apply least privilege.
- Protect local credentials.
- Protect local storage.
- Restrict physical interfaces.
- Rotate credentials.

Updates
- Sign edge software.
- Authenticate firmware updates.
- Authenticate application components.
- Authenticate model updates.
- Stage deployments.
- Support rollback.
- Monitor update status.
- Test power loss during update.
- Keep recovery path.

Containers
- Use containers only where resources justify them.
- Pin image versions.
- Verify image provenance.
- Restrict privileges.
- Avoid unnecessary host access.
- Limit CPU and memory where appropriate.
- Patch runtime.
- Monitor failed containers.

Operating system
- Minimize installed packages.
- Disable unused services.
- Patch security vulnerabilities.
- Restrict SSH.
- Use unique administrator credentials.
- Protect boot process.
- Monitor disk health.
- Monitor kernel and service failures.

Physical security
- Consider public access.
- Consider factory access.
- Consider vehicle access.
- Protect debug ports where justified.
- Protect removable storage.
- Protect credentials from extraction.
- Use secure boot where appropriate.
- Encrypt sensitive storage where useful.

Observability
- Monitor CPU.
- Monitor memory.
- Monitor disk.
- Monitor temperature.
- Monitor process health.
- Monitor message queue.
- Monitor upload backlog.
- Monitor connectivity.
- Monitor update status.
- Monitor inference latency.

Application monitoring
- Track events processed.
- Track events filtered.
- Track data uploaded.
- Track dropped events.
- Track invalid input.
- Track processing errors.
- Track model confidence where useful.
- Track local action outcomes.

Fleet monitoring
- Track gateway inventory.
- Track software version.
- Track model version.
- Track certificate expiration.
- Track last seen.
- Track free disk.
- Track backlog.
- Track restart count.
- Track failed updates.

Costs
- Estimate device hardware cost.
- Estimate gateway hardware cost.
- Estimate installation.
- Estimate backhaul.
- Estimate cloud bandwidth.
- Estimate cloud storage.
- Estimate gateway replacement.
- Estimate field maintenance.
- Compare total lifecycle cost.

Complexity
- Count edge components.
- Count deployed services.
- Count update channels.
- Count databases.
- Count runtime dependencies.
- Document ownership.
- Avoid distributed-system complexity without concrete benefit.

Small project
- Start with simple on-device filtering.
- Use cloud storage for history.
- Add gateway only when it solves a real requirement.
- Avoid complex orchestration on a single simple gateway.
- Keep local data model small.
- Monitor essential health.

Industrial project
- Separate safety control from analytics.
- Keep critical loops deterministic.
- Validate hardware watchdogs.
- Provide redundant networking where required.
- Test offline operation.
- Test gateway failure.
- Maintain controlled update procedures.

Camera workloads
- Consider local motion detection.
- Consider local object detection.
- Upload events instead of constant video where requirements permit.
- Protect local video storage.
- Account for GPU or accelerator power.
- Preserve evidence windows where required.

Audio workloads
- Consider local wake-word detection.
- Avoid continuous cloud audio upload when unnecessary.
- Measure processor load.
- Protect sensitive recordings.
- Define retention.

Predictive maintenance
- Collect high-rate local signals.
- Extract features.
- Calculate anomaly score.
- Upload summaries.
- Upload raw window on anomaly.
- Keep model version with result.
- Validate false-positive rate.
- Validate false-negative risk.

Bandwidth failure
- Reduce upload rate.
- Preserve priority events.
- Drop low-value data according to policy.
- Buffer bounded history.
- Recover gradually.
- Avoid overwhelming WAN after reconnect.

Cloud reconnect
- Add jitter.
- Limit upload concurrency.
- Upload oldest required data appropriately.
- Preserve event timestamps.
- Deduplicate.
- Monitor backlog age.
- Do not let backlog hide current critical events.

Gateway replacement
- Back up configuration centrally.
- Automate provisioning.
- Reissue identity.
- Restore required local state.
- Reconnect downstream devices.
- Avoid making one physical gateway irreplaceable.

Decision: on device
- Choose when latency is extremely important.
- Choose when operation must continue without network.
- Choose when raw data should stay local.
- Choose when computation is small.
- Choose when radio transmission costs more energy than processing.
- Choose when a gateway is unnecessary.

Decision: gateway
- Choose when several devices need local coordination.
- Choose when devices lack compute resources.
- Choose when local buffering is important.
- Choose for protocol conversion.
- Choose for site-level analytics.
- Choose for medium-size ML inference.

Decision: cloud
- Choose when large compute resources are required.
- Choose for long-term storage.
- Choose for fleet-wide analytics.
- Choose for centralized model training.
- Choose when latency is not critical.
- Choose when connectivity is reliable enough for the workload.

Final review
- Does this decision require very low latency?
- Must it work without Internet?
- Is the raw data sensitive?
- Is raw data much larger than the useful result?
- Can the device handle the CPU load?
- Can the device handle the RAM requirement?
- Can the device handle the energy cost?
- Does the workload require several local devices?
- Would a gateway reduce device complexity?
- Can the gateway be updated securely?
- Can it be monitored?
- Can local storage fill?
- Is configuration authority defined?
- Are stale commands rejected?
- Can buffered telemetry be replayed safely?
- Can the cloud tolerate a reconnect backlog?
- Are model updates versioned and authenticated?
- Is edge software patched?
- Is the architecture simpler than the problem it solves?
- Is each computation running at the layer where it provides the clearest practical benefit?

15. FAQ

What is edge computing in IoT?

Edge computing means performing some processing, decision making or storage close to the devices that produce data rather than sending every raw event to centralized cloud infrastructure first.

What is on-device processing?

On-device processing runs directly on the embedded hardware inside the product. Examples include sensor filtering, threshold detection, local control logic, feature extraction and appropriately sized machine-learning inference.

When should IoT data be processed locally?

Local processing is particularly useful when latency must be low, critical functionality must survive Internet outages, raw data is expensive to transmit, privacy favors minimizing raw-data movement, or only a small derived result needs to reach the cloud.

What is an IoT edge gateway?

An edge gateway is a local computing system positioned between sensors and wider network infrastructure. It can translate protocols, aggregate devices, buffer telemetry, run analytics and provide local coordination.

Does edge computing replace cloud computing?

Usually no. Edge and cloud processing complement each other. Local systems handle latency-sensitive, offline and data-reduction workloads, while the cloud remains useful for long-term history, fleet-wide analytics, centralized management and large-scale model training.

Can machine learning run on a microcontroller?

Yes, when the model, runtime and feature-processing pipeline fit the processor, memory, flash, energy and latency budget. Larger models may require an edge gateway or cloud service.

What is the biggest downside of edge computing?

Edge processing distributes software and state across more physical systems. Those systems must be updated, secured, monitored, synchronized and recovered, so edge computing should solve a concrete operational requirement rather than being added by default.

Key terms (quick glossary)

Edge computing

Computing performed close to where data is generated or consumed rather than exclusively in centralized cloud infrastructure.

On-device processing

Computation executed directly by the embedded processor inside the IoT device.

Edge gateway

A local computing system that connects devices to wider networks and may provide protocol translation, buffering, processing, storage or local control.

Cloud processing

Computation performed in centralized remote infrastructure with access to scalable compute, storage and fleet-wide data.

Edge AI

Machine-learning inference or related AI processing executed on or near the device producing the input data.

Inference

Using a trained machine-learning model to produce a prediction, classification, score or other output from new input data.

Latency

The delay between an input or event and the resulting communication, processing or action.

Local control loop

A control process in which sensor input and actuator decisions remain within local infrastructure rather than requiring a remote cloud round trip.

Data reduction

Reducing raw data volume through filtering, aggregation, compression, feature extraction or event detection before transmission or storage.

Feature extraction

Transforming raw sensor input into smaller measurements or properties useful for analytics or machine learning.

Offline buffering

Temporarily storing data locally while upstream connectivity is unavailable so that it can be transmitted later.

Backlog

Accumulated data or work waiting to be transmitted or processed after downstream capacity or connectivity becomes available.

Desired state

The configuration or operating state that a management system wants a device to reach.

Reported state

The state that the device reports it is currently using or observing.

Hybrid edge-cloud architecture

An architecture that deliberately divides workloads between local devices, gateways and centralized cloud systems.