The Philosophy Behind RobustMQ
We are doing something slow — building the next generation of messaging infrastructure.
There are no shortcuts here. The core of infrastructure software is trust, and trust comes from time and depth, not from speed or hype. We choose to slow down, think through every design decision carefully, and write every line of code with rigor.
This post explains what we believe, the principles we follow, and where we are going.
What We Believe
We believe slow is fast.
Infrastructure software has no shortcuts. A wrong architectural decision may not show its cost until three years later. We would rather spend ten times as long in the design phase than pay a hundred times the cost in production.
Every feature we say "no" to represents a deliberate tradeoff. Every direction we say "not yet" to reflects a judgment about timing. Speed is not the goal. Being right is.
We believe technical depth is the real moat.
Tools can be copied, code can be generated, but a deep understanding of a problem cannot be replicated. We spend a lot of time understanding the essence of messaging systems — not just how protocols are implemented, but why they were designed that way, where they break down, and what the next era will demand.
This depth will not translate into competitive advantage in the short term, but it is the reason we will still be here in the long run.
We believe open source is the right path for infrastructure software.
Closed-source infrastructure is incomplete infrastructure. Users need to be able to read the code, audit the implementation, and fix problems themselves in edge cases. This is not just a business strategy — it is our conviction about what infrastructure should look like.
Open source is also the most effective way to build trust. The code is right there. No black boxes, no hidden risks.
We believe as scenarios change, tools must follow.
Kafka is good. RabbitMQ is good. NATS is good. They were designed for the previous era, and they were the right answer for the problems of that era. After AI Agents arrived, the scenario changed — messages are no longer just data, they carry intent; routing is no longer just address matching, it requires semantic understanding; security is no longer just transport encryption, it requires intent auditing.
When the scenario changes, good engineers ask: are the existing tools enough? We believe they are not. That is why RobustMQ exists.
Our Design Principles
One: Unified storage, multiple protocol views
Data is written once and read through the views of different protocols. MQTT devices, Kafka data pipelines, NATS microservices, mq9 Agents — all running on the same storage layer, sharing the same data, just from different angles.
This is not about supporting multiple protocols for its own sake. It is because real systems are heterogeneous. Forcing users to deploy a separate infrastructure stack for each protocol creates complexity instead of solving problems.
One dataset, multiple views — that is our definition of "unified."
Two: Single binary, scale on demand
One binary file, deployable anywhere — edge devices, private data centers, public cloud. Single-node deployment means compute and storage are co-located; multi-node deployment means they are separated. Same code, choose based on need.
This principle comes from observing real scenarios: industrial edge devices need minimal deployment, enterprise cloud environments need elastic scaling. There should not be two separate products to maintain different scenarios. One binary, all scenarios.
Three: No unnecessary dependencies
Every new dependency is a new failure point, a new operational burden, a new security boundary to maintain. We are strict about dependencies — if we can avoid adding one, we do; if an existing solution works, we do not add a new one.
This principle comes up in every design review: do we really need this dependency? Is there a simpler way?
Four: Protocols are interfaces, storage is the core
Protocols change; storage does not. MQTT will evolve, Kafka's protocol will be upgraded, and protocols that don't exist today may appear tomorrow. If protocols and storage are tightly coupled, every protocol change requires modifying the storage layer — that is the wrong architecture.
We designed the storage layer to be protocol-agnostic. Protocols are just interfaces for accessing data. Adding a new protocol requires no changes to storage; optimizing the storage layer benefits all protocols.
Five: Solve the problem at hand — do not over-engineer for hypothetical futures
We have seen too many systems fail because of over-engineering — making current systems extremely complex to support scenarios that may never materialize.
Our principle: use the simplest solution that solves the current problem, and upgrade the solution when the problem actually becomes more complex. Good architecture is not designed upfront — it evolves in real scenarios.
Where We Are Going
Near-term: become the unified solution for heterogeneous communication
A typical industrial system today includes MQTT devices, NATS microservices, and Kafka data pipelines — three systems, three operations teams, three monitoring setups. We want to turn those three into one.
Not by forcing users to migrate to a single protocol, but by letting one infrastructure natively support all protocols without requiring users to change a single line of code.
Mid-term: become the communication infrastructure for the AI era
AI Agent collaboration requires a new communication model — asynchronous, persistent, semantically aware. mq9 is our answer to this need: each Agent has a mailbox; messages wait there until processed. Sender and receiver do not need to be online at the same time.
This is just the beginning. We believe the next generation of messaging systems should understand semantics, sense intent, and have built-in service discovery. Middleware evolving from "mindlessly moving bits" to "a communication network that understands intent" — that is the direction we are exploring.
Long-term: define the next generation of messaging standards
Kafka defined the messaging standard for the big data era, and that judgment shaped the entire industry for a decade. The AI era needs new standards, and those standards have not yet been defined.
We do not know what the final answer looks like, but we believe we are on the right path — starting from the mailbox, the smallest correct abstraction, and discovering step by step in real scenarios what should come next.
Defining standards is a slow process. We are not in a hurry.
Finally
RobustMQ is a judgment in progress.
We believe infrastructure software requires time to accumulate, that technical depth is the real barrier, and that the communication infrastructure of the AI era will look very different from what exists today.
We are expressing these judgments in code.
Welcome to join us and help get this right.