Event-Driven Architecture for Manufacturing: Events, Brokers, Streams and Mesh

Event-driven architecture in manufacturing means that plant and enterprise systems stop asking each other for data and start announcing what has happened. A filler that stops publishes “stopped”, a batch that completes publishes “complete”, a quality check that fails publishes the result, and every system that cares receives the message through a broker within milliseconds. SCADA, MES, ERP, historians, maintenance and analytics all draw on the same flow of events instead of a web of polling jobs and point-to-point interfaces.

Most plants already run fragments of this: an MQTT broker behind a dashboard, a message queue inside the MES, a Kafka cluster owned by the data team. What they rarely have is a design that ties those pieces together. This guide explains the ideas underneath (events, brokers, streams, mesh and governance), how the vendor landscape divides, and a maturity model to judge where your architecture stands. It is vendor-neutral. Where a reader wants one product in depth, we link to our independent Solace guide, one option among several.

Events versus requests: the core idea of event-driven architecture

A request asks; an event tells. In a request-driven design, the MES calls the line controller or the historian every few seconds and asks whether anything changed. In an event-driven design, the line publishes a message when something changes, and the MES, the historian and anyone else subscribed receive it. The difference sounds small. In practice it decides how a plant’s integration ages.

Dimension	Request and response (polling, APIs)	Event-driven (publish and subscribe)
Who starts the exchange	The consumer asks	The producer announces
Coupling	Caller must know the provider’s address and wait for it	Producer and consumers only know the broker and the topic
Adding a new consumer	Usually a new interface, often a change to the provider	A new subscription; the producer does not change
Latency	Bounded by the polling interval	Close to the moment of the change
Network and controller load	Grows with every poller, even when nothing changes	Proportional to real changes
Failure behaviour	A slow provider blocks every caller	A broker can buffer while a consumer is down
Best for	Commands, queries, transactions that need an immediate answer	State changes, notifications, fan-out to many systems

Neither replaces the other. A recipe download or a work order release is a command, and it should get a clear answer. A machine state change is an event, and it should not need twelve systems polling for it. Good architectures use both, deliberately. Our article on PLC scan cycles and SCADA polling explains why polling load matters at the controller level.

How event-driven integration grew up

Event-driven integration is not new. It began in banks and telecoms, reached the plant floor through MQTT, and is now converging with data platforms and AI. The milestones below explain why today’s vendor landscape looks the way it does.

When	Milestone	Why it matters to a plant today
Early 1990s	IBM’s MQSeries (now IBM MQ) and other message-oriented middleware spread through banking	Queues and guaranteed delivery became standard practice; many ERP integrations still run on them
1999	MQTT designed by Andy Stanford-Clark and Arlen Nipper for pipeline telemetry over constrained links	The lightweight publish and subscribe protocol that later suited plant devices
2003	Enterprise Integration Patterns by Hohpe and Woolf	Gave integrators a shared vocabulary: channels, routers, publish-subscribe, point-to-point
2011	Kafka open-sourced by LinkedIn, later an Apache project	Introduced the replayable log as an integration backbone for data platforms
2014 to 2019	MQTT 3.1.1 becomes an OASIS standard (and ISO/IEC 20922:2016); MQTT 5.0 follows in 2019	A vendor-neutral device protocol with standard behaviour across brokers
2016	Cirrus Link introduces Sparkplug for MQTT; version 3.0 later becomes ISO/IEC 20237:2023	A common topic and payload convention for OT data (Eclipse)
2021	The Linux Foundation takes AsyncAPI under its wing	Event interfaces gain a documentation standard, the sibling of OpenAPI (Linux Foundation)
2023 to 2024	AsyncAPI 3.0 released (December 2023); CNCF graduates CloudEvents (January 2024)	Contracts and common metadata for events reach maturity
2025 to 2026	Kafka 4.0 removes ZooKeeper; IBM completes its acquisition of Confluent in March 2026	The streaming market consolidates, which matters when choosing a long-term vendor

The unified namespace sits alongside this history. HiveMQ credits the term to Walker Reynolds (HiveMQ), who popularised it through 4.0 Solutions. It is a pattern, not a product or a standard, and it is usually the first event-driven design a plant builds. Our UNS guide covers the pattern itself.

The building blocks of an event-driven architecture

Events

An event is a fact about the past. “Line 3 filler stopped at 14:02:11 with reason code 42” is an event. It is immutable: a later event can supersede it, but nothing edits it. Martin Fowler’s often-cited essay separates four styles that all get called “event-driven” (Fowler):

1. Event notification: “something changed, ask me if you need detail.” Small and cheap, but it can bring polling back through the side door.
2. Event-carried state transfer: the event carries the data the consumer needs. This is the usual plant pattern: the payload holds the new state.
3. Event sourcing: the system of record is the sequence of events, and current state is rebuilt from it. Rare in plants, common in some MES and finance designs.
4. CQRS: separate models for writing and reading. Useful context when a vendor’s MES documentation uses the term.

Agree which style you mean before an argument about the broker. Most plant disagreements we see about “events” are really disagreements about this.

Brokers: messaging

A message broker receives events and pushes them to subscribers. It routes on topics (often hierarchical, such as site/area/line/cell/metric), keeps queues for consumers that are offline, tracks acknowledgements, and discards messages once every consumer has them. MQTT brokers, JMS and AMQP brokers, IBM MQ, RabbitMQ and Solace all sit here. The Enterprise Integration Patterns names the two core shapes: publish-subscribe (each subscriber gets a copy) and point-to-point (each message goes to one of several competing consumers).

Streams: the log

An event streaming platform writes every event to a durable, ordered, partitioned log and keeps it for a configured retention period. Consumers pull at their own pace and track their own position (the offset), so a new consumer can replay last week’s events. Apache Kafka defined this model; Pulsar, Redpanda and the cloud streaming services follow it. The Kafka design documentation explains why the log is fast and what it costs. Our Kafka vs MQTT page sets the two models side by side.

Mesh: brokers connected across sites

One broker serves one site well. A manufacturer with twelve plants, two data centres and a cloud tenant needs events to cross those boundaries with buffering, filtering and security. An event mesh links brokers so that subscriptions propagate and events route to wherever a consumer lives, instead of hand-building a bridge per flow. What is an event mesh explains the variants: dynamic routing, replication, bridging and federation.

Governance: names, schemas and contracts

Without governance, an event-driven architecture becomes a new kind of spaghetti: hundreds of topics nobody can explain, payloads that change without notice, and consumers that break silently. Governance has four parts:

• A topic convention, usually shaped by ISA-95 (ISA), written before the first topic exists
• Schemas for payloads (JSON Schema, Avro or Protobuf), held in a registry and versioned
• Contracts that document who publishes and consumes what, using AsyncAPI
• Common metadata, such as the CloudEvents envelope (source, type, id, time), so tools can handle events they did not design for

Delivery guarantees, ordering and replay

The promise a broker makes about delivery decides what a plant can build on it. These are the terms every vendor uses, and they are worth knowing precisely.

Guarantee	Meaning	Plant example where it is enough	Where it is not
At most once	Sent once; may be lost, never duplicated	A temperature value republished every second	A batch completion or a goods receipt
At least once	Retried until acknowledged; may be duplicated	Most production and quality events, if consumers handle duplicates	Counters that are summed without a unique event id
Exactly once	Each message has its effect once	Financial postings, inventory moves	Rarely end to end: it usually holds within one platform, not across systems

Design consumers to be idempotent. In our IT/OT integration experience, “exactly once” across a PLC, a broker, an MES and an ERP is not something any single product guarantees end to end. The dependable approach is at-least-once delivery with a unique event id, so a consumer that sees the same event twice can ignore the second copy. MQTT expresses these levels as QoS 0, 1 and 2 (OASIS MQTT 5.0); Kafka documents its own semantics (Kafka). Note that some brokers and cloud services accept QoS 2 but deliver at QoS 1, so check the conformance notes of whatever you choose.

Ordering is per stream, not global. Kafka keeps order within a partition; brokers keep order within a queue or topic. If a consumer needs every event for one batch in sequence, the key that decides partition or queue must be the batch id.

Replay changes recovery. A log-based platform, or a broker with a replay feature, can resend past events to a consumer that was down or newly added. A consumer that missed four hours during an MES upgrade catches up from the log instead of from a manual reconciliation. That is the strongest operational argument for keeping some history in the event layer.

One event, end to end: an illustrative example

The scenario below is illustrative, assembled from patterns that recur across plants rather than from a single site. It shows what the building blocks do together.

1. The change. A filler on line 3 stops on a jam. The edge gateway reading the controller sees the state tag change and publishes one message to the plant broker on site1/packaging/line3/filler/state, with the new state, the reason code, a timestamp and a unique event id.
2. The plant layer. The SCADA screen, the downtime tracker and the line dashboard are subscribed to that topic and update within a second. Nobody polled the controller.
3. The crossing. A bridge or mesh link forwards events matching site1/+/+/+/state through the DMZ to the enterprise backbone, where they land on a persistent queue for the MES and on a stream for the data platform.
4. The outage. The MES is down for a planned upgrade. Its queue holds the events, and when it reconnects it receives them in order and discards any duplicate by event id.
5. The analysis. A week later, a reliability engineer adds a new consumer that replays the month’s stop events from the stream to build a Pareto of jam causes. The filler, the gateway and the MES were not touched.

Every step relies on a decision made earlier: the topic convention, the payload schema, the delivery guarantee, the conduit through the DMZ and the retention period. That is why the governance rules above and the maturity model below matter more than the brand of broker.

The vendor landscape for event-driven architecture

Gartner’s research splits event broker use cases into application messaging, enterprise messaging, event streaming and edge messaging, and advises against one technology for every case (as summarised by Solace). We agree with that advice. The archetypes below map the market; facts are as of October 2026.

Archetype	Examples	Home ground	Where it stops
MQTT and IIoT brokers	HiveMQ, EMQX, Eclipse Mosquitto, Cirrus Link Chariot, broker modules in Ignition and HighByte	Device and plant data, Sparkplug, the single-site UNS	Enterprise protocols, long retention
Enterprise messaging	IBM MQ, RabbitMQ, ActiveMQ, TIBCO EMS	Transactions, ERP and mainframe integration, queues	Device protocols at scale, multi-site routing in some products
Event streaming	Apache Kafka and Confluent (now IBM), Redpanda, Apache Pulsar, Amazon MSK	Analytics, data platforms, replay, stream processing	Small devices, push to many lightweight consumers
Multi-protocol event mesh	Solace, NATS, SAP Integration Suite advanced event mesh (built on Solace)	Many sites and clouds, several protocols on one backbone	Long analytical retention; plant-level Sparkplug awareness varies
Cloud-native services	AWS IoT Core and EventBridge, Azure Event Grid and Event Hubs, Google Cloud Pub/Sub	Single-cloud estates, zero operations	On-premises plants, multi-cloud

The archetypes overlap at the edges. Kafka added queue semantics (KIP-932), MQTT vendors add enterprise features, and mesh vendors bridge to Kafka. Our event broker comparison applies the same dimensions to each major product, and the Solace alternatives page looks at the field from one vendor’s position.

Where event-driven architecture sits on the ISA-95 stack

Most manufacturers end up with layers, not one broker. The pattern below is the one we would expect in a multi-site manufacturer, and it is useful for deciding which product belongs where.

ISA-95 level	Typical systems	Messaging role	Typical technology
Levels 0 to 2	PLCs, drives, HMIs	Field protocols; edge publishing by exception	OPC UA, EtherNet/IP, Modbus, via gateways
Levels 2 to 3	SCADA, MES, historian	Plant broker: current state, Sparkplug, the UNS	An MQTT broker on site
Levels 3 to 4	ERP, quality, PLM, data platforms	Enterprise backbone: guaranteed delivery, fan-out, WAN resilience, several protocols	An event mesh, Kafka, or enterprise messaging
Cloud and analytics	Lakehouse, machine learning, AI agents	Streaming ingest and replay	Kafka and cloud streaming services

The line between the plant broker and the enterprise backbone is also a security boundary. Events should cross the DMZ through a defined conduit, not because a broker on the plant network accepts connections from the corporate one. Our guide to OT network segmentation in brownfield plants covers that design, and choosing a UNS broker covers the plant layer in detail.

A maturity model for event-driven architecture in manufacturing

Gartner has published its own EDA maturity model. The version below is ours, written for plants, and judged by what an operations team can actually do at each level.

Level	Name	What it looks like	What the plant can do
0	Point to point	Polling, file drops, database links and custom interfaces between pairs of systems	Each new system costs a new interface; nobody has a full map
1	Single broker	One broker on one site, often MQTT behind dashboards or a pilot UNS	Real-time visibility on that site; new consumers are cheap
2	Governed namespace	Written topic convention, payload schemas, documented events, access control	Teams reuse events instead of asking for new interfaces
3	Connected enterprise	Plant brokers linked to an enterprise backbone with guaranteed delivery, buffering across the WAN and a bridge to the data platform	Multi-site reporting, ERP and quality flows run on events
4	Event-native	Contracts in AsyncAPI, a catalogue, replay for recovery, events consumed by analytics and AI agents as a matter of course	New use cases are mostly configuration; the event catalogue is the integration map

Where to aim. A single-site plant with a modest integration estate gets most of the value at level 2. A multi-site manufacturer with central quality, planning or analytics needs level 3, because those functions depend on events from every plant arriving reliably. Level 4 earns its cost where there is an enterprise data platform and a team that will own the catalogue.

Assess on the weakest flow. A plant that runs a tidy UNS for dashboards but still sends production confirmations to ERP through a nightly file is at level 1 for the flow that matters most to finance.

The guides in this section

Most asked

• Kafka or MQTT for plant data? Different jobs, and the common pattern that uses both
• Which broker for a unified namespace? One site or many, Sparkplug or not, and who will run it
• How does Solace compare with Kafka? Event messaging against event streaming, from one vendor’s side
• What works in Solace’s MQTT support? The documented limits a plant should know before using an enterprise broker for MQTT

What event-driven architecture means for a plant

It is an integration decision before it is a technology decision. The broker is the easy part to buy. The harder parts are agreeing what an event is, how it is named, who owns each one and what a consumer may rely on. In our IT/OT integration work, the projects that struggle are rarely the ones with the wrong broker; they are the ones where three teams invented three topic trees.

Controls engineering and IT both have to own it. The plant broker lives near SCADA and is often run by controls engineers. The enterprise backbone lives with IT or the integration team. The contract between them, which events cross, at what quality and through which conduit, needs a named owner on each side. An IT/OT integration engagement usually starts by writing that contract down.

It shifts load away from controllers. Publishing on change from an edge gateway, instead of letting every system poll the PLC, reduces traffic on the control network and the controller’s communication load. That is a reliability benefit as much as an integration one.

It makes recovery and auditing easier, if events are kept. A broker with persistent queues or a log with retention can replay what a consumer missed. An MES outage then ends with a catch-up, not a week of reconciliation between the floor and ERP.

It needs the same rigour as the network. Events cross zones. Access control per topic, TLS, certificates and a documented conduit through the DMZ belong in the design from day one, as they would for any other path between OT and IT.

Start small, but write the rules first. One use case, one site, one broker, and a topic and payload convention written before the first publish. Then document every event as a contract. A modernization roadmap is where we would place that first step in the context of the plant’s wider systems.