Modern Connectivity · ASP ENGINEERING LIBRARY

MQTT Store and Forward: Buffering Industrial Data Through Outages

In this article 6 sections

Store and forward retains data during a communication outage and sends it after the connection returns. MQTT delivery options are part of the design, but they do not by themselves prove that a complete historical sequence reaches a database. Define persistence, capacity, replay ordering, and duplicate handling at the application boundaries.

MQTT Store and Forward: Buffering Industrial Data Through Outages — Capture → Buffer → Replay → Reconcile.
MQTT Store and Forward: Buffering Industrial Data Through Outages — Capture → Buffer → Replay → Reconcile. View full size

Design the requirement before the configuration

Distinguish a broker session queue from an edge application’s durable local buffer. Specify what survives process restart and power loss, how full storage is handled, and whether new live data takes priority over replay. Assign each record a stable identity and retain its original timestamp. A downstream consumer should be able to detect gaps and apply an idempotent write policy where repeated delivery is possible. A retained MQTT message is a latest-value mechanism, not a history archive.

Worked scenario

Illustrative capacity calculation: 50 records per second at an average 200 encoded bytes per record require 36 MB per hour before storage and protocol overhead. An eight-hour outage therefore needs at least 288 MB for payload alone. Measure actual disk usage, index overhead, and replay throughput; include headroom and an explicit full-buffer policy.

What to verify

CheckEvidence to record
PersistenceTest application restart and approved power-loss scenarios
CapacityMeasure stored bytes and define a full-buffer policy
ReplayRetain source time and expose replay progress
ConsumerDetect missing IDs and tolerate expected duplicate delivery

Acceptance and handover

Disconnect the upstream path in a representative test, let the backlog grow, then restore it while new records continue arriving. Compare the sent and committed record identities. Measure catch-up time and confirm that operators can distinguish current readings from delayed history.

A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.
A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded. View full size

Continue the engineering work

Use the related technical library for deeper background, or follow an ASP project guide to plan the implementation sequence.

Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

Use this guide in context. Examples are engineering starting points. Confirm device documentation, site requirements, and acceptance criteria before implementation. How this library is maintained · Suggest a correction

FROM REFERENCE TO REAL PROJECT

Bring your next automation challenge.

PLC and DCS engineering, OPC connectivity, and digital transformation. Start with your installed systems, your constraints, and what you need to achieve.

Talk to ASP OTOMASYON