Grab a chair before proceeding.
You’re about to access the full Coreflux platform. Some people report weakness in their knees upon first contact.
You’ve been warned.
.png)
Product Update
Somebody wrote a script. It pulls from MQTT, reshapes a few things, pushes into Kafka. It runs on a VM whose name nobody can remember. It loses data when it restarts, though not enough for anyone to have noticed properly. One person understands it.
Most companies discover how much they depend on that script in the week that person changes jobs.
It is the same duplicated-stack problem as running two brokers, just further up the chain. And the return path, getting a decision back down to the plant floor, was never built at all.
Apache Kafka keeps a durable, ordered record of everything that happened. Systems write events into it, other systems read them at their own pace, and can go back and read history again later. Nothing has to be captured in the moment or lost. A new team can point a new tool at last year's data without anyone reproducing the original events.
That permanence is the point. Kafka is not a faster message bus, it is a system of record for data in motion. It sits underneath most modern data platforms, warehouses, analytics tools and AI pipelines. If a company has a data team, there is a good chance Kafka is already running.
They solve different problems, and a good architecture uses both for what each is best at.
| MQTT | Kafka | |
| Built for | Devices and control, thousands of connections coming and going | Data pipelines, analytics and replay |
| How long data lives | Moments, it is in flight | As long as you choose, hours to forever |
| Volume | High | Very high, orders of magnitude more |
| Who lives here | The plant floor | The data team |
MQTT handles fast-moving device traffic across unreliable connections. Kafka holds the lasting record that data teams build on. The Kafka Connector is the belt between the two warehouses, and it runs in whichever direction you point it.
The OPC UA Server and Modbus Server Connectors make Coreflux the convergence layer facing the plant, the system SCADA and HMIs read from. The Kafka Connector does the same work facing the business.
With it, the path from a sensor on a line to the warehouse or model that needs it is one governed step, described in Language of Things alongside the rest of your setup. The return path, whether that is a command, a setpoint, or the output of a model that decided something should change, is the same connection rather than a separate project.
This is also where the AI architecture story becomes concrete. Coreflux is not the model. Coreflux is the infrastructure that gets the right data to whichever model you have chosen, and gets the answer back to the field. The Kafka Connector is one end of that path.
Both directions, one connection. Plant data going out to the business and instructions coming back in are handled together, rather than as two integrations that have to be kept in step.
Per-asset history can be kept in order. Key your readings by machine and everything from that machine arrives in the sequence it happened. That ordering is what makes the data usable for trend analysis, fault diagnosis and model training, rather than only for monitoring. It is a choice you make when you set the connection up, not something that happens by itself.
It works with the cluster they already run. Confluent Cloud, Amazon MSK, Aiven, Azure Event Hubs, Redpanda, or self-managed Apache Kafka. This is rarely a greenfield conversation. The data platform usually exists, and the plant is the thing not feeding it.
Credentials stay out of the configuration. Encrypted connections and the authentication methods enterprise clusters expect, with passwords held outside the definition rather than written into it.
Restarts do not re-read from zero. On the way in from Kafka, the connection commits its position only after the data has actually landed. Pick-up after a restart happens where you left off, and a failed handoff is retried rather than skipped.
Analytics and AI without a bespoke pipeline. The same connection that fills the warehouse can carry a model's decision back down to a setpoint on the plant floor.
Enterprises and global system integrators where the data platform team already runs Kafka and the plant is the last thing not feeding it. Digital and IoT product companies whose analytics stack assumes a continuous stream of data. Anyone currently maintaining a homegrown bridge between their broker and their data platform, and hoping its author does not leave.
Cluster connection, security options, message keys and throughput tuning are in the technical documentation.
%20(1).png)
%2520(1).png)