RobustMQ Gateway: A Minimal Access Layer for a Multi-Protocol Ecosystem

Overview

RobustMQ Gateway is a module inside the RobustMQ broker. It exposes three methods over gRPC: send, receive, and ack. Applications only need to specify a topic — no knowledge of any underlying protocol required.

Why does this exist? RobustMQ already supports MQTT, Kafka, NATS, AMQP, and mq9, each with its own full semantics and ecosystem. But in practice, many use cases don't need that complexity. They just need to write data to a topic and have it reliably received on the other end. Choosing a protocol, learning an SDK, and managing upstream/downstream protocol coupling is overhead for application teams, not value.

Gateway addresses exactly two problems: lower the barrier to entry, and decouple upstream from downstream.

On its own, it's not competitive — there are plenty of simple message queues on the market. But inside RobustMQ's multi-protocol architecture, it becomes a meaningful addition. Data sent through Gateway enters the unified storage layer, and downstream consumers can use Kafka, MQTT, mq9, or any other supported protocol. The upstream doesn't need to change when the downstream changes, and vice versa. That's where Gateway's real value lies.

---

Core Value: Upstream and Downstream Move Independently

Gateway has two design goals: keep it simple, and neither side needs to change.

Once data is written through Gateway, it enters RobustMQ's unified storage layer. Downstream can consume it with any protocol — a Kafka consumer, an MQTT subscriber, or Gateway's own receive. Upstream doesn't need to know what protocol downstream uses, and downstream doesn't need to know how upstream writes.

Upstream                         Downstream
send(topic, data)  →    Kafka consumer
                   →    MQTT subscriber
                   →    receive(topic)
                   →    receive(topic, stream=True)

Upstream changes, downstream stays the same. Downstream changes, upstream stays the same. Both sides evolve independently.

This is especially valuable for systems carrying legacy debt. Dozens of upstream services are locked into a protocol they can't migrate off — once they go through Gateway, all they know is a topic. Whatever happens to the underlying protocol or storage layer is invisible to them.

---

Relationship to Existing Protocols

Gateway is not a protocol — it's an access method. It sits alongside MQTT, Kafka, NATS, AMQP, and mq9, but serves a different purpose. Those are protocols; Gateway is a minimal ingress channel that reuses RobustMQ's unified storage layer underneath.

  MQTT  |  Kafka  |  NATS  |  AMQP  |  mq9  |  Gateway
────────────────────────────────────────────────────────
                    Unified Storage Layer

No replacement, only addition. Teams with clear protocol requirements keep using their protocol. Teams that don't want to choose use Gateway. Pick what fits — no forced migration.

---

Server-Side gRPC

Gateway uses gRPC for its transport layer. gRPC is a mature, production-grade RPC framework: interfaces defined in protobuf, SDKs generated per language, connection management, retries, timeouts, and TLS all handled by the framework, with native server streaming support. For Gateway, gRPC means zero SDK development cost — Python, Go, Java, Rust, JavaScript, and C# are all covered, fully aligned with RobustMQ's existing SDK matrix.

Interface definition:

service RobustMQGateway {
  rpc Send(SendRequest) returns (SendResponse);
  rpc Receive(ReceiveRequest) returns (ReceiveResponse);
  rpc ReceiveStream(ReceiveRequest) returns (stream Message);
  rpc Ack(AckRequest) returns (AckResponse);
}

Receive and ReceiveStream are two modes of the same semantic: pull and streaming push.

---

SDK Interface

The SDK wraps the gRPC interface into three methods. The stream parameter selects between pull and streaming mode:

# Write a message
client.send(topic, payload)

# Pull (fetch a batch at once, maps to Receive)
msgs = client.receive(topic, limit=10)
for msg in msgs:
    process(msg)
    client.ack(topic, msg.msg_id)

# Stream (messages pushed as they arrive, maps to ReceiveStream)
for msg in client.receive(topic, stream=True):
    process(msg)
    client.ack(topic, msg.msg_id)

# Acknowledge a message so it won't be redelivered
client.ack(topic, msg_id)

No protocol selection. No consumer group. No offset management. One topic, three methods.

---

Summary

Gateway isn't about adding another protocol, and it's not about building a new message queue product.

A standalone send/receive/ack message queue has no real market position — there are too many of those already.

But in practice, this kind of lightweight access layer is genuinely popular. There's less to configure, fewer concepts to learn, and neither side needs to change. Applications like simple things.

What Gateway is really betting on is RobustMQ's multi-protocol architecture and its unified storage foundation. Once that's in place, Gateway's value is qualitatively different — upstream and downstream can evolve independently, even within the same project. No migration cost. Things that work today keep working. Teams can converge at their own pace.

Gateway is an addition, not a requirement. But as an addition sitting on top of RobustMQ's multi-protocol, unified-storage architecture, it carries real weight.

Lower system complexity means lower risk. That's one of RobustMQ's core values: reduce system complexity for applications and organizations — not by asking users to migrate to a new stack, but by giving them more options at lower cost on top of what they already have.