Messages

A message (also called a record or event) is the fundamental unit of data transferred in FlowMQ. It contains the information that a producer sends to one or more consumers through a topic. FlowMQ's message structure is designed to be:

• Simple: A straightforward container for data and metadata
• Flexible: Support for any payload format (JSON, Protobuf, binary, etc.)
• Protocol-Agnostic: Seamlessly translatable between MQTT, AMQP, Kafka and other protocols

This design ensures that no matter which protocol a client uses to connect, it can interact with a consistent and feature-rich message object.

Message Structure

A FlowMQ message is composed of the essential elements a producer sends:

1. Topic: The destination topic name for the message (e.g., sensors/us/california/temperature). This is a fundamental part of the message, as it determines how the broker will route it.

2. Headers: A collection of key-value pairs (both strings) used to store application-specific metadata. This can include content types, tracing IDs, or processing instructions.

3. Payload: The raw content of the message, represented as a byte array ([]byte). The payload can be anything—JSON, Protobuf, plain text, or binary data. FlowMQ is content-agnostic and does not inspect or validate the payload.

A Message ID is an optional, unique identifier that is typically assigned by the broker when a message is received. While not part of the producer-defined structure, it is critical for operations like acknowledgement and tracing.

Here's a conceptual representation of a message sent by a producer:

┌──────────────────┐
│      Topic       │ (e.g., "sensors/us/california/temperature")
├──────────────────┤
│     Headers      │ (e.g., {"content-type": "application/json"})
├──────────────────┤
│                  │
│     Payload      │ (e.g., {"value": 22.5, "unit": "celsius"})
│                  │
└──────────────────┘

Protocol Mapping

FlowMQ's unified message model allows it to seamlessly translate messages to and from other protocols.

FlowMQ Component	MQTT Message	AMQP 1.0 Message	Kafka Record
Topic	Topic	to / subject	Topic
Headers	User Properties	Application Properties	Record Headers
Payload	Payload	Body / Data	Value
Message ID	Broker-Generated	message_id	Broker-Generated

This internal mapping ensures that a message published via an AMQP client with specific application properties can be consumed by an MQTT 5 client, which will see those same properties as user properties. The core information and metadata are preserved across the ecosystem.