MQTT Connectivity for Iggy

[ygndotgg]

Summary

This proposal evaluates three ways to introduce MQTT connectivity to Iggy without committing to a single implementation upfront. The key question is where MQTT protocol handling and state should live while keeping Iggy Core focused on its streaming responsibilities.

The technical evaluation is discussed in three sub-proposals:

1. Proposal A: MQTT Connector (External Broker + Connector) — [#3385]
2. Proposal B: Dedicated MQTT Gateway/Proxy — [#4201]
3. Proposal C: Native In-Process Protocol Surface — [#4182]

1. Strategic Context & Motivation

MQTT is widely used for IoT and edge workloads. MQTT connectivity would allow existing MQTT clients to interact with Iggy.

Core Design Consideration: Keep MQTT-specific protocol handling and broker state outside Iggy Core, while preserving Iggy's focus on high-performance streaming, storage, partitions, offsets, and replication.

2. Integration Models

Model 1: MQTT Broker + Iggy Connector

MQTT Clients ──► MQTT Broker ──► Iggy Connector ──► Iggy

An external MQTT broker terminates MQTT connections and provides broker semantics. The connector handles data movement between the broker and Iggy.

Pros

• Full broker functionality: MQTT sessions, QoS, retained messages, subscriptions, and other broker semantics are handled by the external broker.
• Strong isolation: MQTT connections and broker state remain outside the Iggy server process.
• Minimal Iggy Core impact: No MQTT protocol implementation is required inside Iggy Core.
• Independent scaling: Broker and connector can scale independently of Iggy.

Cons

• Higher operational footprint: Requires an MQTT broker in addition to Iggy and the connector.
• Additional communication stages: Introduces additional data movement and potentially more latency/buffering than a direct gateway.

---

Model 2: Dedicated Standalone MQTT Gateway (iggy-gateway-mqtt)

MQTT Clients ──► MQTT Gateway ──► Iggy SDK / Protocol ──► Iggy

A standalone process terminates MQTT and translates MQTT operations into Iggy operations. This follows the standalone gateway approach being explored for Kafka.

Pros

• Process isolation: MQTT connection handling and protocol failures remain outside the Iggy server process.
• No MQTT implementation in Core: MQTT parsing, connection lifecycle, and protocol handling remain in the gateway.
• Independent lifecycle: Gateway versions, scaling, and restarts are independent of Iggy server releases.
• Brokerless compatibility: MQTT clients can connect directly without deploying a separate full MQTT broker.

Cons

• Additional component: Requires an independently deployed gateway process.
• Additional network boundary: Gateway-to-Iggy communication adds a network stage compared with an in-process listener.
• Explicit protocol scope: MQTT features such as retained messages, persistent sessions, and complex subscription state would need to be intentionally implemented if required.

---

Model 3: Native In-Process MQTT Surface

MQTT Clients ──► Iggy Server ──► Native MQTT Runtime ──► Iggy Core

MQTT handling is implemented directly inside the Iggy server process.

Pros

• Direct connectivity: No separate gateway or gateway-to-Iggy network boundary.
• Single deployment unit: MQTT functionality is packaged with the Iggy server.
• Server infrastructure reuse: Can reuse existing listener, TLS, lifecycle, and authentication infrastructure.

Cons

• Shared failure and resource domain: MQTT uses the same process CPU, memory, file descriptors, and runtime resources as Iggy.
• Higher Core maintenance surface: MQTT parsing, sessions, configuration, and delivery logic become part of the server implementation and tied to single core (Shard 0 Bottleneck).
• Coupled lifecycle: MQTT changes become tied to Iggy server testing and release cycles.
• Delivery complexity: Stateful MQTT delivery may require connection queues, acknowledgements, subscription state, and coordination with Iggy offsets.

---

3. Architectural Comparison Matrix

Dimension	Model 1: Broker + Connector	Model 2: MQTT Gateway	Model 3: Native MQTT
MQTT Termination	External Broker	Gateway	Iggy Server
Core MQTT Impact	None	None	Increased
MQTT State	Broker	Gateway scope	Iggy process
Failure Domain	Separate	Separate	Shared
Deployment	Broker + Connector + Iggy	Gateway + Iggy	Iggy only
Network Path	Multiple stages	Client → Gateway → Iggy	Client → Iggy
Scaling	Independent broker/connector	Independent gateway	Coupled to Iggy
Primary Role	Data integration	Protocol compatibility	Native protocol support

[richardcocks]

My two cents: I'm not sure what it means to be a bridge and not a broker.

A client as source or sink makes sense, but I don't think writing a half-broker into Iggy does, just let people run mosquito or other broker with a real feature set.

[ygndotgg]

I agree with the concern I don't think Iggy should become a half-broker or compete with general-purpose MQTT brokers like Mosquitto or EMQX. For users needing full MQTT semantics, the broker + Iggy connector model makes more sense.
What I'm exploring is a narrower option: a thin native MQTT wire interface, similar to Iggy's HTTP/WebSocket interfaces, where MQTT Layer handles the wire protocol and minimal client-facing state, while MQTT packets are translated directly into Iggy operations without introducing broker semantics into the core.