Messaging Model

FlowMQ's messaging model is protocol-independent. Producers publish messages with topics, FlowMQ routes them to matching destinations, and consumers receive them from those destinations.

Basic Flow

1. A producer publishes a message with a topic.
2. FlowMQ matches the topic against filters bound to streams, queues, and subscriptions.
3. Each matching destination receives a copy of the message.
4. Consumers receive messages from those destinations.

Producers and consumers are decoupled. Producers do not need to know which destinations or consumers exist, and consumers do not need to know which producer sent a message.

Messages

A message is the data unit that moves through FlowMQ. It contains an application payload and optional headers. The topic associated with the message when it is published is its routing address.

Field	Description
Payload	Application data, such as JSON, text, Protobuf, or binary data
Headers	Optional key-value metadata, such as content type, schema identifiers, tracing context, or tenant identifiers

FlowMQ does not require a specific payload format. Producers and consumers determine how to encode and decode the payload.

Topics and Topic Filters

A topic is a hierarchical routing address whose levels are separated by /:

sensors/factory-1/temperature
orders/us/created
devices/vehicle-42/status

Producers publish to concrete topic names. Consumers do not consume from topics directly; destinations select messages with topic filters.

Topic filters support two wildcards:

Wildcard	Meaning	Example
+	Matches one topic level	sensors/+/temperature
#	Matches zero or more levels at the end	sensors/#

For example, sensors/+/temperature matches sensors/room-1/temperature, while sensors/# also matches sensors/room-1/humidity.

Producers and Consumers

A producer creates a payload, selects a topic, adds optional headers, and publishes the message. FlowMQ determines where to route the message, so destinations can be added or changed without changing the producer.

A consumer receives messages from a stream, queue, or subscription. Its delivery, recovery, and scaling behavior depends on the destination type.

Destinations and Bindings

A destination stores or delivers messages for consumers. Streams, queues, and subscriptions are destination types.

A binding connects a destination to one or more topic filters. When a message topic matches any filter in a binding, FlowMQ sends a copy of the message to that destination. A message can be routed to multiple destinations.

Streams

A stream is a durable, ordered, replayable log. It retains messages independently of consumption, so reading a message does not remove it.

Partitions

A stream has one or more partitions. Each partition is an append-only sequence, and each message is appended to one partition.

Partitions allow reads and writes to scale in parallel. Ordering is defined within a partition; a stream has no single global order across partitions.

Offsets

Each message has an offset within its partition. Consumers track an offset for each partition they read, allowing them to resume after reconnecting, read from the beginning, consume only new messages, or reprocess retained messages.

Retention

A stream retains messages according to its retention settings. Messages older than the configured retention period are removed and can no longer be replayed.

Streams are suited to event history, analytics pipelines, audit logs, IoT data retention, and other replayable workloads.

Queues

A queue holds messages until they are consumed. Each message is delivered to one consumer and removed after it is acknowledged.

Delivery Order

Queues deliver messages in first-in, first-out order. Retries, redelivery, and concurrent processing can change the order in which processing completes.

Acknowledgment and Redelivery

A consumer acknowledges a message after processing it. If the message is not acknowledged, FlowMQ can deliver it again. Queue handlers should therefore be idempotent when duplicate processing is possible.

Multiple consumers can share a queue, but each queued message is delivered to only one of them.

Queues are suited to background jobs, worker pools, task distribution, and asynchronous request processing.

Subscriptions

A subscription pushes matching messages to active consumers in real time. It is not durable: if a client disconnects, its subscription is removed, and messages published while it is offline are not retained for that subscription.

Fan-Out

Each active consumer on a subscription receives a copy of every matching message.

Shared Subscriptions

A shared subscription distributes each matching message to one active consumer in the group. It supports scaled real-time processing without sending every message to every consumer.

If no consumer in the group is active, the subscription does not retain messages. Use a queue or stream when messages must remain available while consumers are offline.

Subscriptions are suited to live notifications, dashboards, collaboration updates, and online device or application state.

Choosing a Destination

Requirement	Stream	Queue	Subscription
Retain messages	For a configured retention period	Until acknowledged	No
Delivery model	Each consumer group reads independently	One consumer per message	Every active consumer, or one consumer in a shared group
Replay messages	Yes, while retained	No	No
Typical use	Event history and replay	Work distribution	Live fan-out

What This Model Enables

• Producers and consumers can evolve independently.
• One message can feed multiple storage and delivery models.
• Routing rules can change without changing producers.
• Durable storage and real-time delivery can be configured independently.