5  Cloud Platform Queues

5.1 Start With the Message Path

A platform choice often starts with a messy stream of device messages: some are alarms, some are routine samples, some drive dashboards, and some feed batch analysis. Treating them all as one pipe hides the real design problem.

Start simple: write the path for one message class and name whether it needs a broker, queue, stream, storage service, or worker. The platform is a fit only when it protects that path and leaves proof that it did.

In 60 Seconds

An IoT cloud platform is not just a message endpoint. It combines device identity, secure ingestion, routing, buffering, state synchronization, storage integration, observability, and controlled return paths. Message brokers, queues, and streams solve different problems: brokers connect publishers and subscribers, queues absorb work for processors, and streams keep an ordered event history for replay and analytics.

Minimum Viable Understanding

• A platform decision is a responsibility decision. Decide who operates device identity, ingestion, routing, state, storage, monitoring, and updates.
• Brokers, queues, and streams are not interchangeable. Use each for the role it is built to support.
• MQTT QoS is not end-to-end reliability by itself. It describes delivery between MQTT clients and brokers; downstream processing still needs idempotency and replay rules.
• Capacity records matter more than product labels. Check connections, message rate, payload size, burst shape, retained state, replay window, and operational ownership.
• Avoid platform drift. Record which features are portable, which are service-specific, and what migration or isolation boundary protects the architecture.

5.2 Learning Objectives

By the end of this chapter, you will be able to:

• Describe the core capabilities of an IoT cloud platform.
• Distinguish message brokers, work queues, and event streams in IoT architectures.
• Map message lifecycle stages from device publish to application action.
• Choose MQTT QoS and downstream reliability controls based on consequence, timing, and duplication tolerance.
• Build a capacity and operations record for platform selection without relying on brittle pricing or named-service assumptions.

5.3 Platform Responsibility Map

A cloud platform for IoT usually wraps several responsibilities into one operating surface. Some teams consume those capabilities as managed services. Others assemble them from self-managed components. The architecture check should focus on the responsibilities, not on brand names.

The overview depth layer shows the responsibility map that connects field-side devices and gateways to identity, ingestion, routing, observability, state, storage, and controlled return paths.

Evaluate these platform responsibilities separately:

• Device identity: how devices prove who they are, rotate credentials, and get retired.
• Ingestion: how telemetry, events, files, commands, and device-health signals enter the system.
• Routing: how messages move to alerts, storage, analytics, and operations workflows.
• State: how desired state, reported state, last-seen time, and configuration changes are tracked.
• Buffering: how bursts, retry storms, and downstream outages are absorbed.
• Retention: which events are kept, for how long, at what level of detail, and for which purpose.
• Observability: how operators see connection health, rejected messages, lag, errors, and data loss.
• Return path: how commands, configuration, model artifacts, and updates move back toward devices.

The result may be one managed platform, a self-managed broker plus shared cloud services, a hybrid site-cloud platform, or a federated design. The review record should explain why that operating shape fits the workload.

5.4 Broker, Queue, Or Stream?

IoT systems often use several message technologies at once. A device-facing broker is not the same as a processing queue, and neither is the same as a replayable event stream.

Figure 5.1: Message brokers, work queues, and event streams serve different roles in an IoT platform.

5.4.1 Message Broker

Primary role: live publish-subscribe communication.

Use when: devices or gateways need topic-based telemetry, commands, status updates, and subscriptions.

Validation record: session behavior, QoS use, topic naming, authentication, authorization, retained messages, and offline handling.

5.4.2 Work Queue

Primary role: buffer tasks for processors.

Use when: downstream services need controlled concurrency, retries, dead-letter handling, and back-pressure.

Validation record: visibility timeout, retry policy, ordering need, idempotency key, poison-message handling, and alerting.

5.4.3 Event Stream

Primary role: ordered event history for replay and analytics.

Use when: teams need time-ordered retention, consumer groups, reprocessing, model features, audit trails, or historical debugging.

Validation record: partition key, retention window, replay owners, schema evolution, lag metrics, and compaction or deletion rules.

Use a broker for connection-facing pub/sub, a queue for work distribution, and a stream for durable event history. Combining them is common: a gateway publishes to a broker, the platform routes accepted events into a stream, and processors read from queues or stream consumers.

5.5 Message Lifecycle

A message lifecycle diagram should show more than “device sends data to cloud.” It should expose the control points where errors, duplicates, routing mistakes, and visibility gaps occur.

Figure 5.2: A cold-storage gateway message moves through identity and topic checks, broker acknowledgment, routing rules, retry queues, retained streams, processing, storage, application action, inspection, and an approved command return path.

For each message family, review:

1. Publish source: device, gateway, application, batch job, or operator action.
2. Identity check: device credential, gateway identity, application token, or service role.
3. Protocol and topic: transport, topic naming, schema, version, and payload size.
4. Acknowledgment: QoS, retry rules, duplicate detection, and timeout behavior.
5. Routing: which rules send the event to alerts, queues, streams, storage, or applications.
6. Processing: transformation, validation, enrichment, aggregation, or inference.
7. Storage: hot state, time-series history, object archive, audit record, or replay stream.
8. Response path: command, configuration, notification, dashboard update, or no return action.

5.6 Platform Selection Route

Choose the platform shape after the workload is understood. Starting with a named platform often hides the real constraints.

Figure 5.3: A platform selection route starts with cold-storage workload intent, then checks connection shape, message roles, technology roles, state retention, stress proof, ownership, portability, and final managed, self-managed, or hybrid platform fit.

Use this route:

1. Name the workload. Examples: device telemetry, command delivery, firmware rollout status, gateway health, alarm workflow, replayable analytics feed.
2. Describe the connection shape. Count always-on connections separately from occasional uploads and batch transfers.
3. Classify message roles. Telemetry, command, alert, state update, audit event, configuration, model artifact, or file reference.
4. Choose broker, queue, stream, or combination. Match the technology role to the message role.
5. Define state and retention. Decide what is last-known state, what is retained history, and what is replayable record.
6. Check timing and burst behavior. Identify peak periods, reconnect storms, rollout waves, and downstream limits.
7. Define operations ownership. Who patches, scales, monitors, rotates credentials, handles incidents, and reviews cost or capacity?
8. Record portability boundaries. Identify service-specific routing rules, state formats, identity assumptions, and migration risks.

5.7 Managed or Self-Managed Platforms

The durable question is not “managed or self-hosted?” The question is “which operating responsibilities should this team own?”

5.7.1 Managed Platform Fit

Useful when the team values faster delivery, built-in identity workflows, managed scaling, operational monitoring, and reduced infrastructure ownership.

Watch for: service-specific routing rules, quota assumptions, data movement limits, and hidden operating dependencies.

5.7.2 Self-Managed Fit

Useful when the team needs deep control over broker behavior, site-local operation, custom protocols, isolated environments, or consistent deployment across many private sites.

Watch for: patching, on-call, backups, upgrades, clustering, capacity testing, security review, and disaster recovery.

5.7.3 Hybrid Fit

Useful when local brokers protect site operation while cloud services handle fleet dashboards, long-term analytics, and cross-site coordination.

Watch for: bridge rules, duplicate handling, local retention, cloud lag, return-path approval, and outage recovery.

5.7.4 Self-Managed Cloud Stack Example

OpenStack is a common example of a self-managed IaaS control plane. It is useful to know because it turns the platform responsibility map into named services that an operations team must install, secure, monitor, and upgrade. The names are not the design goal; the design goal is still the responsibility boundary.

In an OpenStack-style private cloud, Keystone handles identity, authentication, and authorization; Horizon provides the dashboard; Nova launches and manages compute instances; Glance stores and serves virtual-machine images and snapshots; Neutron provides tenant networking; Cinder provides block storage; Swift provides object storage; Heat orchestrates stacks; and Ceilometer or the telemetry service records usage for monitoring and billing. An IoT team using that stack still needs the same release record as any other platform: who owns security groups, key pairs, images, networks, storage volumes, quotas, backups, usage records, and incident response.

For an IoT lab or private deployment, a DevStack installation can prove the workflow at small scale: create a key pair, create a security group, launch an instance, attach networking, and communicate with the instance. That proof should not be mistaken for production readiness. Production use also needs upgrade planning, image hygiene, credential rotation, capacity testing, billing or chargeback records, and recovery drills.

Decision record: The platform shape is acceptable only when the team can name the owned responsibilities, the outsourced responsibilities, the failure behavior, and the validation results that prove the design still works during bursts, outages, credential rotation, and downstream back-pressure.

5.8 QoS And Reliability

MQTT QoS is useful, but it is not the whole reliability design.

5.8.1 QoS 0

Meaning: at most once between publisher and broker.

Fit: frequent telemetry where occasional loss is acceptable and newer readings supersede older readings.

Extra controls: sequence numbers or sampling-quality indicators when loss should be visible.

5.8.2 QoS 1

Meaning: at least once between publisher and broker.

Fit: alerts, state changes, and commands where delivery matters and duplicates can be handled.

Extra controls: idempotency keys, deduplication windows, and safe command handlers.

5.8.3 QoS 2

Meaning: exactly once between MQTT endpoints for that exchange.

Fit: narrow cases where duplicate delivery at the broker boundary is more harmful than added latency and complexity.

Extra controls: end-to-end transaction design, application acknowledgments, and operator review for critical workflows.

Do not use QoS 2 as a blanket safety setting. Many systems are safer with QoS 1 plus idempotent processing, explicit command state, and a clear confirmation path. Reliability should be designed across the full path: device, broker, queue, processor, storage, application, and return command.

5.9 Capacity Records Without Assumptions

Capacity planning should avoid fixed product ratings and changing prices. Use workload records that can be recomputed during architecture checks.

For a message family, record:

• Connection count: always-on devices, gateway sessions, applications, and operators.
• Message rate: average rate, peak rate, burst duration, and reconnect behavior.
• Payload size: raw payload, envelope overhead, compression, and attachments.
• State size: device state documents, retained topics, session buffers, and queued commands.
• Retention: replay window, hot storage, cold archive, and deletion rules.
• Processing limits: consumer concurrency, downstream write rate, retry behavior, and dead-letter thresholds.
• Recovery: time to catch up after outage, maximum acceptable lag, and manual intervention triggers.

Use simple formulas during platform checks:

• Average messages per second = devices x messages per device per hour / 3600.
• Peak messages per second = average messages per second x burst multiplier.
• Daily payload volume = devices x messages per day x average payload bytes.
• Session memory estimate = active sessions x measured memory per session from a load test.

The formula is not the proof. The proof is a load test, replay test, outage drill, or production telemetry sample that validates the assumptions.

5.10 Simulation and Provider Checks

Cloud simulators and named provider stacks are useful when they turn assumptions into repeatable evidence. They should not replace the platform record.

Use simulation when a real deployment would be too slow, expensive, or disruptive to test directly. A simulator record should name the workload, topology, virtual machines or services, scheduling policy, network delay, storage behavior, energy or cost model, and the values changed between runs. Tools in this family include CloudSim-style discrete-event simulation for data centers, VMs, brokers, applications, and users; CloudAnalyst-style experiments for geographically distributed users and data centers; and GreenCloud-style experiments for energy and network behavior inside data-center designs. The result is useful only when the run explains what it did not model, such as provider quotas, managed-service behavior, hardware failures, security controls, or operational support.

Named platforms need the same discipline. OpenStack can be a self-managed IaaS control plane when private-cloud control and integration matter, but it brings ownership of compute, networking, images, storage, patching, monitoring, and upgrade risk. Azure, AWS, and similar public clouds can supply managed compute, storage, messaging, analytics, monitoring, machine learning, and IoT services, but the team still owns workload fit, identity policy, data retention, export, cost review, and recovery evidence. For EC2-style virtual machines, record instance family, storage choice, scaling rule, image maintenance, network policy, and the reason the workload needs VM-level control instead of a more managed runtime.

Treat every simulator or provider comparison as a scenario test, not a ranking table. A useful comparison says which design choice changed, which metric moved, which responsibility shifted, and which proof is still required before production.

5.11 Cold-Storage Platform Messaging

A cold-storage operator has gateways at many facilities. Each gateway receives temperature readings, door events, compressor state, local alarm events, and device-health records. The system needs local alarms, central dashboards, maintenance workflows, and replayable records for investigations.

5.11.1 Workload Placement

Device-facing broker

• Accepts gateway telemetry and device-health updates.
• Uses topic names that include site, device class, and event family.
• Enforces gateway identity and allowed topic patterns.
• Keeps short local buffers during connectivity loss.

Routing and queueing

• Sends urgent alarm events to a work queue with retry and escalation handling.
• Routes accepted telemetry summaries to long-term storage.
• Sends rejected or malformed events to inspection instead of silently dropping them.

Event stream

• Keeps ordered operational events for replay and analytics.
• Lets analytics consumers reprocess events after schema or model changes.
• Tracks lag so teams know when dashboards or reports are stale.

Return path

• Sends approved configuration changes back through a controlled command topic.
• Requires idempotent command handlers on gateways.
• Records command intent, approval, delivery, acknowledgment, and rollback state.

Decision record: The device broker is optimized for secure gateway sessions and topic authorization. Alarm handling uses a queue so processors can retry and escalate. The replay stream holds accepted operational events for investigation and analytics. Configuration changes return only through an approved command path with idempotent handlers.

5.12 Platform Selection Record

The platform selection record is the artifact that keeps the chapter from becoming a product comparison.

Figure 5.4: A platform selection record captures workload intent, message roles, platform responsibilities, capacity records, reliability controls, operations ownership, and portability boundaries.

Include:

• Workload intent: what outcome the platform path supports.
• Message roles: telemetry, alert, command, state, audit, replay, or file reference.
• Technology role: broker, queue, stream, state store, time-series store, object store, or application API.
• Reliability controls: QoS, retries, idempotency, deduplication, dead-letter handling, and replay.
• Capacity record: connection count, peak rate, payload size, retention, lag, and load-test result.
• Operations owner: monitoring, scaling, credential rotation, patching, incident response, and check cadence.
• Portability boundary: where service-specific rules, state formats, or deployment assumptions exist.

5.13 Common Pitfalls

Do Not Pick by Feature Lists

Feature lists hide operations risk. Check the responsibilities the team will own: identity, patching, routing rules, scaling, storage, monitoring, and response to outages.

2. Treating A Broker As A Database

A broker can retain selected state or sessions, but it should not be the only long-term record store. Send accepted events to storage or a retained stream when replay or audit is required.

3. Ignoring Duplicate Messages

Retries, reconnects, QoS 1 delivery, and downstream failures can create duplicates. Use idempotency keys and safe processors when duplicates would harm analytics or operations.

4. Hiding Failed Messages

Malformed, unauthorized, or repeatedly failing messages need an inspection path. Silent drops make data gaps difficult to investigate and can hide device defects.

5.14 Platforms Map Message Duties

An IoT cloud platform is a set of responsibilities around messages, not a single endpoint. The design must say who proves device identity, who accepts messages, where work is buffered, which events are retained for replay, which state is synchronized, and how commands return toward the field.

Use the platform responsibility map to keep identity, ingestion, routing, storage, observability, state, and return-path duties visible before choosing a managed, self-managed, or hybrid shape.

Mobile summary: A cloud platform decision is a responsibility decision: prove device identity, accept messages, route work, retain evidence, observe failures, synchronize state, and control commands back to the field.

The broker, queue, and stream answer different parts of that map. A broker handles live publish-subscribe communication, a queue controls processor work, and a stream keeps accepted events available for replay, analytics, and audit.

Keep the first review at message-family level. Room temperature telemetry, compressor-fault alarms, gateway health reports, firmware rollout status, and setpoint commands should not be forced through one generic “cloud messaging” answer. Each family has a different identity check, delivery consequence, retention need, and owner.

For overview review, ask three questions. Which component proves the sender is allowed to publish? Which component absorbs work when downstream processors are slow? Which component keeps accepted events long enough to replay or audit them? If those answers point to different components, the platform design should say so explicitly.

Broker

Owns live topics, sessions, authentication, authorization, retained messages, and offline behavior at the connection-facing boundary.

Queue

Owns work dispatch, retry timing, back-pressure, dead-letter handling, and alerting when processors cannot keep up.

Stream

Owns ordered event history, retention, consumer lag, schema evolution, and replay after analytics or model changes.

A strong platform choice can trace each message family from publish source to accepted record, processing owner, retained history, and return path.

That trace should also name what is not proven. A broker acknowledgement does not prove dashboard freshness. A queue retry does not prove long-term history. A stream replay window does not prove that a command reached a gateway. The overview record should keep those boundaries visible before the team chooses managed, self-managed, or hybrid platform pieces.

A useful minimum record therefore has four columns: message family, platform role, evidence produced, and owner. For example, telemetry may name the broker topic and accepted-event store, alarms may name the queue and escalation owner, replay analytics may name the stream and retention window, and commands may name the return path plus acknowledgement rule. This keeps the overview small while still proving the architecture is more than a product label.

During the first pass, avoid mixing operational promises into one vague availability target. A platform can be available for telemetry while alarm processors are overloaded, replay consumers are behind, or command acknowledgements are delayed. The overview should therefore name the user-visible consequence for each message family: stale dashboard, missed escalation, incomplete audit, unsafe command state, or delayed maintenance action.

5.15 Platform Selection Record

Write one record per major message family. The record should not merely say “use managed IoT” or “self-host MQTT.” It should tie workload behavior to the component role, validation evidence, operations owner, and retest trigger.

Message Family

Platform Role

Validation Evidence

Owner And Retest Trigger

Live telemetry

Broker accepts authenticated publishes and routes accepted events.

Topic authorization, payload limits, QoS behavior, and reconnect burst test.

Platform operations; retest after topic, credential, gateway, or burst-shape change.

Alarm workflow

Queue controls retry, escalation, and processor concurrency.

Retry timing, poison-message path, dead-letter alert, and duplicate-safe processor proof.

Application operations; retest after severity, retry, processor, or escalation-policy change.

Replay analytics

Stream retains accepted events for replay and consumer groups.

Retention window, schema version, lag metric, replay drill, and backfill owner.

Data platform; retest after model, schema, retention, or partition-key change.

Command return

Broker or command service sends approved configuration and action messages.

Authorization, idempotent handler, acknowledgement state, rollback path, and timeout behavior.

Device and platform owners; retest after command type, firmware, role, or safety rule change.

Use the record to separate normal traffic from stress cases. A platform that handles average telemetry may still fail during a power recovery when every gateway reconnects, resends buffered samples, refreshes credentials, and asks for pending commands. The record should include reconnect-storm behavior, rejected-message inspection, queue catch-up time, and the owner who decides whether to shed, defer, replay, or escalate work.

Also record the portability boundary. Topic naming, rule engines, device shadows, retained state, stream partition keys, and dead-letter formats can become service-specific. That is acceptable when the team names the dependency, tests the export or migration path that matters, and knows which release or compliance event would force a review.

For a cold-storage deployment, a useful record might say: alarm events use QoS 1 into the broker, include an idempotency key, enter a queue with dead-letter alerting, and write accepted alarm state to an audit stream. Temperature summaries use a replay stream with schema version and consumer-lag alert. Commands use a command id, authorization check, gateway acknowledgement, timeout, and rollback owner. Those details make the platform choice testable.

5.16 Reliability Across Boundaries

MQTT QoS can confirm delivery between MQTT endpoints, but it does not prove downstream processing, storage, replay, dashboard state, or command execution. Each boundary needs its own failure rule, duplicate rule, and inspection path.

At the broker boundary, the key questions are session identity, topic authorization, retained-message behavior, duplicate publishes, and whether the acknowledgement means “accepted by broker” or “processed by the application.” At the queue boundary, the questions change to visibility timeout, retry count, idempotency, poison-message handling, and when a failed message becomes an incident. At the stream boundary, the questions are partitioning, ordering scope, retention, schema evolution, lag, and replay authority.

Under load, these boundaries interact. A reconnect storm can create duplicate QoS 1 deliveries, queue backlogs, stream lag, dashboard staleness, and delayed commands at the same time. The release record should therefore connect sequence numbers or idempotency keys to the processor, not only to the broker. It should connect dead-letter records to operator action, not only to a storage bucket. It should connect replay windows to the investigation questions the team actually needs to answer.

Broker Ack

Proves the broker exchange, not whether a processor stored the event, an alert fired, or an operator saw it.

Queue Retry

Protects processors only if visibility timeout, idempotency, dead-letter handling, and alerting are configured together.

Stream Replay

Works only when retention, partitioning, schema evolution, consumer lag, and replay authority are owned explicitly.

Command Return

Needs authorization, idempotent handlers, acknowledgement state, timeout behavior, and rollback before it is safe to operate.

Treat every platform boundary as a contract. If a message crosses broker, queue, stream, storage, application, or command-return boundaries, the record must name what is proven at that boundary and what remains unproven.

Command return paths need the same treatment. A command record should include command id, requested state, target group, authorization decision, delivery attempt, gateway acknowledgement, application completion proof, timeout rule, and rollback owner. Without those fields, a platform can show that a command was published while still leaving operators unsure whether the field system accepted or safely applied it.

This is why “exactly once” claims need careful wording. A protocol or service may narrow duplicate behavior for one exchange, but the IoT outcome still depends on application handlers, storage writes, retries, human workflow, and gateway state. The deeper platform proof is a chain of small contracts, each with its own evidence and owner.

For replay and audit, the boundary is not only technical; it is also interpretive. A stream partition key decides which events keep order together. A schema version decides which consumers can safely replay old records. A retention rule decides whether an incident can still be investigated. A lag alert decides when analytics are stale enough to stop trusting a dashboard. Those choices should be recorded beside the broker and queue settings because they change what the platform can prove after an outage or model defect.

Security boundaries also change the reliability claim. Mutual TLS or token validation proves a session identity, not that the device is healthy, calibrated, or authorized for every topic. Topic authorization proves publish permission, not that a payload schema is valid. Schema validation proves shape, not physical truth. The platform record should keep these proofs separate so incident review can locate the failing boundary quickly.

The same separation helps cost and capacity review. Broker connection limits, queue depth, stream retention, storage writes, and alert fan-out scale on different drivers. If the team records the driver at each boundary, it can retest the right part when gateway count, sampling rate, retention policy, or command frequency changes.

5.17 Summary

Cloud platforms and message queues should be selected by workload responsibility, not by brittle named-service comparisons. A durable IoT messaging architecture separates live device communication, work buffering, retained event history, state synchronization, storage integration, and controlled return paths. The quality gate is a validation record: capacity assumptions, QoS and retry behavior, replay tests, dead-letter handling, observability, operations ownership, and portability boundaries.

5.18 Key Takeaway

Cloud platforms should be compared by message responsibilities, reliability boundaries, operations ownership, replay needs, and team operating capability.

5.19 See Also

Continue with:

• Cloud Service Models for IoT for responsibility boundaries across SaaS, PaaS, IaaS, and FaaS.
• Cloud Deployment Models for IoT for workload placement and hybrid boundary records.
• Cloud Security for IoT for device identity, access boundaries, and secure return paths.
• Production Cloud Deployment for monitoring, scaling, rollout, and operations readiness.