Using MQTT at Scale: Where Things Usually Go Wrong

Jakub — Wed, 14 Jan 2026 07:42:34 +0000

“Just Publish It”… and Suddenly Nothing Talks to Each Other

(MQTT, UNS, and why patterns matter)

“It’s just MQTT — we’ll figure it out as we go.”

A few sprints later:

half the topics mean different things to different teams

payloads drift without anyone noticing

dashboards disagree

and debugging feels like archaeology, not engineering

If this sounds familiar, the problem usually isn’t MQTT itself — it’s how it’s being used.

A useful concept to know: Unified Namespace (UNS)

Unified Namespace (UNS) isn’t a product. It’s an architecture pattern for event-driven data integration.

Instead of tightly coupling systems or wiring producer → consumer relationships directly, you publish data once into a shared, structured namespace. Everything else subscribes.

From a software perspective, this usually means:

fewer hard dependencies between services

clearer boundaries between producers and consumers

changes that are easier to reason about

better visibility into what data exists and how it flows

Often, MQTT is used as the transport layer — but MQTT alone doesn’t give you structure, semantics, or safety. That’s where patterns matter.

Why teams adopt this pattern

When done well, UNS helps teams avoid a lot of familiar pain:

fewer fragile “don’t touch anything” integrations

clearer data context (what / where / when) so downstream code doesn’t guess

easier onboarding of new consumers (dashboards, analytics, ML, alerting)

simpler debugging — you can trace who published what and when

a natural place to enforce data contracts and versioning

But none of this comes “for free” just by introducing MQTT.

Do’s ✅ (software-friendly)

Treat topic structure like an API surface
Design hierarchy and naming intentionally. Changing topics later is a breaking change, even if it doesn’t look like one.

Use explicit data contracts
Schemas, units, timestamps, quality flags, ownership. Version them like you would any public interface.

Build observability in from day one
Health topics, heartbeats, last-known-state patterns, metrics, logs. If you can’t observe it, you can’t debug it.

Don’ts ❌

Don’t turn the namespace into a data dumpster
“Just publish everything” scales badly. Curate signals, model events, keep semantics tight.

Don’t ship silent breaking changes
Changing schemas, units, or timestamps without versioning recreates point-to-point pain — just hidden behind pub/sub.

Don’t skip governance
ACLs, ownership, lifecycle rules, and lightweight review processes matter more than broker choice.

I wrote this because I’ve seen too many teams lose weeks to “small” MQTT changes that should’ve been boring — but weren’t, because patterns were missing.

If you want a practical breakdown of UNS with MQTT, including best practices, common patterns, and where teams usually get stuck, here’s the full article:

👉 https://ttpsc.com/en/blog/unified-namespace-mqtt-best-practices/

“Just a Tiny Data Change”… and Your OT Stack Falls Apart (UNS to the Rescue)

Jakub — Mon, 12 Jan 2026 08:15:34 +0000

“It’s just a tiny data format change,” someone said.
Two hours later: SCADA’s gone silent, MES is offended, and ERP is pretending it’s never met these people.

If that feels familiar, it’s usually a symptom of tight coupling and point-to-point integration sprawl: lots of custom connectors, hidden assumptions, and changes that ripple through the stack in weird, non-obvious ways. It works… until it doesn’t (and somehow it’s always Friday).

A useful concept to know: Unified Namespace (UNS)

UNS is less a “tool” and more an architecture pattern for data integration. Think event-driven, not “sync systems directly.”
Instead of every consumer calling every producer, you publish once into a shared, structured stream, and services subscribe to what they need (often implemented with pub/sub tech like MQTT).

From a software perspective, it’s basically:

fewer direct dependencies
clearer boundaries
more predictable change management
better observability of what data exists and how it flows

Why teams use this pattern?

fewer fragile “don’t touch anything” integrations
clearer data context (what / where / when) so downstream code doesn’t guess
easier to add new consumers (dashboards, analytics, ML, alerting) without re-wiring everything
easier debugging because you can trace “who published what and when”
a more natural place to enforce data contracts and versioning

Do’s ✅ (software-friendly)

Define a topic structure + naming conventions early (treat it like an API surface, not an afterthought).
Use data contracts: schemas, units, timestamps, quality flags, and explicit ownership. Version changes like you’d version an API.
Bake in observability: health/heartbeat topics, last-known-state patterns, and logs/metrics so you can actually troubleshoot.

Don’ts ❌

Don’t treat UNS as a data dumpster. “Just publish everything” becomes technical debt fast. Curate signals, model events, keep semantics tight.
Don’t ship breaking changes silently (schema/unit/timestamp changes). That’s how you recreate point-to-point pain, just in pub/sub form.
Don’t skip governance: ACLs, ownership, lifecycle rules, and a simple review process for changes. Without this, the architecture won’t save you.

I wrote this because I’ve seen too many teams lose weeks to “small” integration changes that should’ve been boring.
If you’ve got questions (or integration horror stories), drop them in the comments — happy to go deeper on contracts, versioning strategies, topic design, or where these projects usually get stuck.

If you want a practical breakdown with examples, here you go:
👉 [https://ttpsc.com/en/blog/what-is-unified-namespace/]

DEV Community: Jakub

Using MQTT at Scale: Where Things Usually Go Wrong

“Just a Tiny Data Change”… and Your OT Stack Falls Apart (UNS to the Rescue)