Publish/Subscribe (Pub/Sub)

Decoupled, Event-Driven Communication at Scale

FlowMQ is built on the proven publish/subscribe (pub/sub) messaging model, a fundamental communication pattern that enables scalable, event-driven architectures. With FlowMQ's unified approach, you can leverage pub/sub messaging across multiple protocols—MQTT, Kafka, AMQP, and NATS—all through a single platform.

The Publish/Subscribe (pub/sub) messaging model decouples message producers (publishers) from message consumers (subscribers), allowing systems to communicate asynchronously without knowing about each other's existence. Unlike traditional point-to-point communication, pub/sub creates a flexible, scalable foundation for modern distributed systems.

In the pub/sub model, publishers send messages to topics without knowing who (if anyone) will receive them. Subscribers express interest in specific topics and receive all messages published to those topics, without knowing who published them. This decoupling is mediated by a message broker—like FlowMQ—that handles the routing, delivery, and management of messages across different protocols seamlessly.

How Pub/Sub Works

The pub/sub model operates through three core components:

1. Publishers

Publishers are clients that produce and send messages to specific topics. They:

• Create and format messages containing data or events
• Specify the topic where the message should be published
• Send messages to the broker without knowing about subscribers
• Can publish messages at any time, whether subscribers exist or not

2. Topics

Topics are named communication channels that categorize messages. They:

• Serve as logical addresses for message routing
• Can be hierarchical (e.g., sensors/temperature/room1)
• Support pattern matching and wildcards in many systems
• Exist independently of publishers and subscribers

3. Subscribers

Subscribers are clients that express interest in receiving messages from specific topics. They:

• Subscribe to one or more topics or topic patterns
• Receive messages asynchronously as they are published
• Can join or leave subscriptions dynamically
• Process messages according to their application logic

4. Message Broker

The message broker is the central component that:

• Accepts messages from publishers
• Routes messages to appropriate subscribers based on topic matching
• Manages topic subscriptions and subscriber lists
• Handles message persistence, delivery guarantees, and quality of service

Pub/Sub Communication Flow

Here's how a typical pub/sub interaction works:

1. Subscriber connects to broker and subscribes to topic "sensors/temperature"
2. Publisher connects to broker
3. Publisher sends message "25°C" to topic "sensors/temperature"
4. Broker routes message to all subscribers of "sensors/temperature"
5. Subscriber receives and processes the "25°C" message

Topic Patterns and Wildcards

Most pub/sub systems support flexible topic matching through wildcards and patterns:

Hierarchical Topics

Topics are often organized in hierarchies using separators like / or .:

• home/livingroom/temperature
• home/bedroom/humidity
• office/floor2/motion

Wildcard Subscriptions

Subscribers can use wildcards to receive messages from multiple related topics:

Single-Level Wildcard (+ in MQTT)

• Subscription: home/+/temperature
• Matches: home/livingroom/temperature, home/bedroom/temperature
• Doesn't match: home/livingroom/sensor/temperature

Multi-Level Wildcard (# in MQTT)

• Subscription: home/#
• Matches: home/livingroom/temperature, home/bedroom/humidity, home/kitchen/lights/status

Design Patterns

Fan-out Pattern

One publisher sends messages to multiple subscribers:

Fan-in Pattern

Multiple publishers send messages that are consumed by one subscriber:

Request/Reply Pattern

Pub/sub can simulate request/response communication:

Message Filtering Pattern

Subscribers use topic patterns to receive only relevant messages:

Advantages of Pub/Sub

1. Loose Coupling

Publishers and subscribers are completely decoupled:

• No direct connections between producers and consumers
• Systems can be developed, deployed, and scaled independently
• Changes to one component don't affect others

2. Scalability

The model naturally supports horizontal scaling:

• Multiple publishers can send to the same topic
• Multiple subscribers can consume from the same topic
• Message brokers can be clustered and distributed

3. Flexibility

Dynamic subscription management enables flexible architectures:

• Subscribers can join or leave at runtime
• New message types can be added without changing existing code
• A/B testing and feature flags become easier to implement

4. Asynchronous Communication

Non-blocking message delivery improves system performance:

• Publishers don't wait for subscribers to process messages
• Subscribers process messages at their own pace
• Systems remain responsive under varying loads

5. Broadcast Capability

One-to-many communication is built-in:

• Single message can reach multiple subscribers
• Efficient for notifications and event distribution
• Eliminates need for multiple point-to-point connections

FlowMQ and Pub/Sub

FlowMQ implements the pub/sub model across multiple protocols, allowing you to:

• Use MQTT for lightweight IoT communication
• Leverage Kafka for high-throughput data streaming
• Mix protocols seamlessly through unified topics
• Scale from IoT sensors to enterprise data pipelines

Whether you're building IoT applications, microservices architectures, or real-time analytics systems, the pub/sub model provides the foundation for scalable, maintainable, and flexible messaging solutions.