Unified Topics

One Topic, Any Protocol. Natively.

At the heart of FlowMQ platform is a powerful, unique feature we call Unified Topics. This feature fundamentally changes how you work with different messaging protocols, eliminating complexity and unlocking seamless interoperability across your entire architecture.

In short, Unified Topics allow a single, logical topic to be accessed by clients using different messaging protocols—like MQTT, Kafka, AMQP, and NATS — as if they were all speaking the same language.

What are Unified Topics?

Every topic in FlowMQ is a unified topic. It is a core architectural concept that messages are routed based on within our platform. Unified topics are not accessed directly by clients—instead, clients of different messaging protocols use their native syntax to access the underlying unified topic.

FlowMQ Topic Structure

A FlowMQ topic itself is very similar to MQTT topics. It uses / as a separator, contains multiple levels, and supports MQTT-style topic filters like + and # for wildcard matching:

• Single-level wildcard (+): Matches any single topic level
  • sensors/+/temperature matches sensors/home/temperature and sensors/office/temperature
• Multi-level wildcard (#): Matches multiple topic levels at the end
  • sensors/home/# matches sensors/home/temperature, sensors/home/humidity, and sensors/home/living/temperature

Different messaging protocols map to FlowMQ's unified topics using automatic, zero-configuration conversion:

MQTT Topic Mapping

MQTT topics map almost directly to unified topics with minimal transformation:

• MQTT topic: sensors/home/livingroom/temperature → FlowMQ topic: sensors/home/livingroom/temperature

Kafka Topic Mapping

Kafka topics use dot notation, which gets converted to the unified topic's slash notation:

• Kafka topic: sensors → Unified topic: sensors
• Kafka topic: sensors.home.livingroom.temperature → Unified topic: sensors/home/livingroom/temperature

Unified Message Routing

FlowMQ's unified topics makes seamless cross-protocol communication possible. When a message is published to a topic using any supported protocol, it becomes immediately available to consumers using any other protocol—all without bridges, adapters, or complex configuration.

How Message Routing Works

The unified routing system operates at the core of FlowMQ's architecture:

1. Message Ingestion: When a client publishes a message using their native protocol syntax, FlowMQ automatically maps it to the internal unified topic structure
2. Message Routing: Messages are routed to their all subscribers according to their internal topic structures
3. Real-time Delivery: Messages are delivered to matched consumer clients by their native protocol

Cross-Protocol Communication Scenarios

Kafka to MQTT Communication

Microservice (Kafka) → FlowMQ → Mobile App (MQTT)

1. Order service publishes to Kafka topic: orders.notifications.payment
2. FlowMQ stores messages in a stream bound to unified topic: orders/notifications/payment
3. MQTT mobile app subscribes to: orders/notifications/payment
4. Push notifications are delivered instantly

MQTT to Kafka Communication

IoT Device (MQTT) → FlowMQ → Data Processing Service (Kafka)

1. IoT sensor publishes to MQTT topic: sensors/factory/line-a/temperature
2. FlowMQ stores message in a stream bound to unified topic: sensors/factory/line-a/temperature
3. Kafka consumer reads from topic: sensors.factory.line-a.temperature
4. No data transformation or message loss occurs

Real-World Use Case: Smart Building System

Consider a smart building system where different components use their preferred protocols:

• Temperature Sensors (MQTT) → building/floor-2/room-201/temperature
• HVAC Control (Kafka) ← building.floor-2.room-201.temperature
• Mobile Dashboard (MQTT) ← building/floor-2/+/temperature
• Analytics Pipeline (Kafka) ← a stream bound to building/#
• Alert System (AMQP) ← building/*/alerts/#

All these systems communicate seamlessly through the same unified topic space, with each using their native protocol syntax and semantics.

This is not a bridge. Traditional bridges connect two separate systems, introducing latency, a single point of failure, and complex configuration. Our Unified Topics feature is a native capability—a single unified core that speaks multiple protocols fluently.

Key Benefits

1. Radically Simplified Architecture

Eliminate the entire class of complex "glue" components. You no longer need to deploy, configure, and maintain separate bridges, connectors, or custom proxy services to get your systems to talk to each other. Your architecture becomes cleaner, more resilient, and easier to understand.

2. Zero Configuration, Maximum Productivity

Unified Topics work out of the box. There are no mapping rules to write or YAML files to configure. The simple, convention-based mapping (/ to .) is automatic. This allows your teams to move faster, focusing on building application logic instead of wrestling with infrastructure plumbing.

3. Ultimate Flexibility & Future-Proofing

Your technology choices are no longer locked in. You can have an IoT fleet publishing data via MQTT, a set of microservices processing that data with Kafka Streams, and a legacy system consuming it over AMQP—all interacting with the same topics effortlessly. As your needs evolve, you can adopt new technologies and protocols without having to re-architect your core messaging layer.

4. Native Performance & Reliability

Because this is a native, in-memory feature, there is no added network hop or serialization overhead that you would find in an external bridge. Messages flow from one protocol to another at the speed of the core platform, ensuring the lowest possible latency and the highest reliability.

Why You'll Love Unified Topics

We designed this feature to solve the real-world frustrations that developers and architects face every day.

• It Just Works: The experience is seamless. You publish a message, and it's simply available everywhere else it needs to be. This intuitive, "it just works" behavior lets you build complex systems with surprising simplicity.
• Freedom to Choose: Use the best tool for the job. Your IoT team can use the lightweight MQTT protocol they love, while your data science team can leverage the powerful Kafka ecosystem. Unified Topics ensure they can collaborate without compromise.
• Build and Iterate Faster: Drastically cut down on development and testing time. By removing the need for interoperability workarounds, your developers can deliver features faster and with more confidence.

Stop bridging, start unifying. With Unified Topics, you can build a truly integrated and resilient system from day one.