Polling vs Publish for Legacy Machine Data
Polling vs Publish for Legacy Machine Data
Section titled “Polling vs Publish for Legacy Machine Data”Legacy lines often force teams to think carefully about how data should be collected after access is established. Polling is familiar and sometimes unavoidable. Publish-style patterns can reduce friction upstream. The mistake is treating this like a pure software preference when the real constraints live at the machine boundary.
Which layer this decision belongs to
Section titled “Which layer this decision belongs to”This decision usually sits between:
- field-side access to controllers or devices;
- local translation or buffering in a gateway;
- upstream delivery to historians, MES, or cloud systems.
That means the right behavior depends on both the machine’s tolerance for being queried and the destination’s expectations.
When polling fits
Section titled “When polling fits”Polling is often the right fit when:
- the source device only exposes simple request-response access;
- the required update rate is modest and well understood;
- the project prioritizes predictable collection behavior;
- the plant wants a conservative first rollout.
Polling can be a perfectly good brownfield answer when used with discipline.
When publish-style behavior helps
Section titled “When publish-style behavior helps”Publish or event-driven patterns become more useful when:
- the upstream systems benefit from decoupled event delivery;
- gateways can normalize and forward changes cleanly;
- the architecture is expanding beyond simple point collection;
- the team wants to reduce the burden of constant line-side queries.
The important point is that publish usually becomes useful after a reliable boundary device is already in place.