MQTT’s legacy: Report by Exception, openness, and the road ahead

By Arlen Nipper, Co-Creator of MQTT and CTO of Cirrus Link Solutions

Just joining us? Read Part 1, Part 2, and Part 3 of the MQTT story.

Once we had the MQTT client and broker model up and running, we began seeing the impact of the architecture, especially when we started eliminating the old poll/response model in favor of Report by Exception (RBE).

This was more than just a new protocol, it was a paradigm shift for industrial systems.

Why report by exception was so disruptive

In traditional SCADA systems, the host had to poll every data point, every cycle. Whether a value had changed or not, it was transmitted, over and over again.

With MQTT sitting on top of TCP/IP, we now had a system where data could be published only when it changed.

By their very nature, any poll/response protocol consumes 100% of a network’s bandwidth. One of the first things we had to do was eliminate that.

Instead of flooding the network with unchanged data, MQTT allowed remote devices to publish updates when needed, and remain quiet otherwise. This was revolutionary for midstream pipelines and other bandwidth-sensitive environments.

We were enabling true event-driven architectures long before that became an industry buzzword.

What we got right (and what it meant)

Looking back with 20/20 hindsight, I believe these core values were key to MQTT’s success:

  • Simple – Could run on low-power, embedded devices
  • Efficient – Designed for bandwidth-constrained networks
  • Bidirectional – Enabled both data collection and control
  • Stateful – Made RBE and real-time monitoring possible
  • Open – We resisted vendor lock-in and embraced open standards
  • Secure – Built on top of TCP/IP; inbound-only connections minimized risk

I had spent 21 years dealing with cryptic proprietary protocols that were poorly documented and felt we should keep the MQTT specification open and free to implement. Andy felt the same way. We both felt strongly that it was time for something open, something that could scale, and something designed around solving real problems.

Where we go from here

MQTT was invented to solve a specific problem for one customer. But its general applicability, and the fact that it didn’t force a one-size-fits-all payload model, meant it could grow beyond that.

Today:

  • There are billions of MQTT clients in the world
  • MQTT is a cornerstone of industrial IoT, home automation, connected vehicles, and more
  • Sparkplug has emerged as a powerful layer on top of MQTT, adding context, state management, and a unified namespace

A final thought

The real magic of MQTT wasn’t in the protocol itself — it was in the mindset:

Solve a real problem. Make it simple. Keep it open.

I’m proud of what Andy and I created. And I’m even more excited to see where this community takes it next.

If you’re using MQTT or Sparkplug, we’d love to hear your story.

Reach me anytime at arlen.nipper@cirrus-link.com.