Product Thinking and Positioning for RobustMQ
RobustMQ is a next-generation high-performance multi-protocol message queue built with Rust. Our vision is to become the next-generation cloud-native and AI-native messaging infrastructure. It is not simply "yet another message queue" — rather, it represents a rethink and redesign of message queues for the AI era and cloud-native requirements.
Since the inception of the RobustMQ project, we have continually examined whether we are falling into the trap of purely technical thinking, whether we are building a product without real business demand, and whether we are merely indulging in technical self-satisfaction.
Over two years of developing RobustMQ, we have received many questions and doubts: that we are "reinventing the wheel," "just another message queue," that "message queue technology is already mature with little room for innovation," and that "the technical vision is too ambitious to achieve."
We are well aware that the correctness of our direction determines the value of all our efforts. Therefore, this article presents our thinking and understanding from a product perspective.
Product Positioning
RobustMQ is positioned as a standard message queue product, in the same category as RocketMQ, Kafka, Pulsar, and RabbitMQ. Our vision is that the evolution of message queue technology can be seen as: RabbitMQ → Kafka → RocketMQ → Pulsar → RobustMQ.
Thus, RobustMQ's product positioning is clear: a standard, enterprise-grade message queue product.
We expect that in the future, when users need to choose a message queue, RobustMQ will be a strong candidate. Users might choose RobustMQ for:
1. Excellent Performance
Delivering high QPS/throughput and stable latency, meeting the stringent performance and throughput requirements of streaming, messaging, financial transactions, and other scenarios.
2. Multi-Protocol Compatibility
Compatibility with mainstream message queue protocols (MQTT, AMQP, Kafka, RocketMQ, etc.) to reduce migration costs while offering better performance, stability, cost control, and scenario coverage.
3. Plugin-Based Storage Architecture
Through a plugin-based storage architecture to meet diverse business scenarios. For example, latency-sensitive scenarios can use local storage, while large-volume, cost-sensitive scenarios can use remote object storage, enabling flexible storage configuration.
4. Unified Technology Stack
A single message queue system can satisfy various message middleware scenarios within an enterprise, eliminating the need to maintain multiple heterogeneous systems and reducing operational complexity and tech stack management costs.
5. Cloud-Native Elasticity
Full elastic scaling capabilities, perfectly suited for Kubernetes architecture, with better cost control and elastic scaling.
From a product perspective, RobustMQ's core value proposition is to serve as an improved alternative to existing message queue products. Through comprehensive advantages in stability, performance, elasticity, cost, scenario coverage, and migration convenience, we aim to attract users to migrate from existing products to RobustMQ.
We believe that RobustMQ's choice to be compatible with existing protocols rather than designing new ones is a critical strategic decision. Designing new communication protocols would require rebuilding the entire ecosystem — SDKs, toolchains, community support, etc. — which would be enormous in effort and difficult to promote. Compatibility with mainstream protocols allows us to reuse the existing ecosystem, focus effort on kernel optimization, and build differentiated competitiveness in performance, stability, elasticity, and cost. Designing new communication protocols would be the start of RobustMQ going in the wrong direction.
Commercial Perspective
RobustMQ has adhered to an open-source-first principle since inception, with the goal of becoming an Apache top-level project. But from a commercial perspective, does RobustMQ have real value? Will its target users recognize that value?
After in-depth analysis, we believe RobustMQ has a clear value proposition commercially. Its target users mainly include two groups: To-B service providers and enterprise customers.
To-B Service Providers (e.g., Cloud Vendors)
Currently, cloud vendor message queue products are mainly based on open-source hosting — hosted Kafka, RabbitMQ, RocketMQ, etc. This model offers low development cost, stable products, and quick revenue. However, from a long-term operations perspective, there are challenges:
1. Differentiation Dilemma
The open-source hosting model makes it difficult to differentiate from other cloud vendors or self-hosted solutions, often leading to price competition focused on resource sales (CPU/memory).
2. The Fork Dilemma
To improve margins and differentiation, cloud vendors typically customize open-source products, but face these issues:
- Cost fragmentation: Customizing every open-source product incurs huge costs and spreads effort thin; customizing only some products limits differentiation and growth
- Community fork risk: Customization can lead to forks from upstream, losing community benefits and making long-term maintenance difficult, potentially reverting to the community version and wasting substantial investment
RobustMQ's design philosophy addresses these pain points. Its elasticity, plugin-based storage, multi-protocol support, and full open-source approach provide an ideal solution for cloud vendors.
For example, once RobustMQ completes multi-protocol, Serverless, and plugin-based storage features, cloud vendors can adapt their own cloud storage engines to meet various message queue scenarios. Compared to maintaining multiple heterogeneous systems, cloud vendors only need to maintain one kernel, significantly reducing long-term labor and operational costs while building differentiated competitive advantages through kernel optimization.
Enterprise Customers
For small enterprises with relatively simple scenarios, differences between message queue products may not be significant. But as enterprises scale and scenarios grow more complex, they often need to deploy multiple message queues. At that point, both business-side selection decisions and infrastructure team operations become costly.
Therefore, many enterprises limit their choice to one or two message queue products to improve system stability, reduce operational costs, and lower talent requirements.
In this context, a unified message queue platform that supports multiple protocols, offers excellent performance, is stable and reliable, scales elastically, and covers diverse scenarios perfectly matches enterprise needs. This is exactly RobustMQ's design goal.
Core Application Scenarios
When RobustMQ matures, we believe the following two scenarios will be important adoption paths:
1. All-in-One Unified Messaging Base
For cloud vendors and large enterprises, providing a unified message queue platform that meets various scenario needs, improves system stability, and reduces overall investment costs.
2. Improved Alternative to Existing Products
For users dissatisfied with existing message queue products in performance, elasticity, cost, etc., offering a better alternative:
- Users with higher requirements for Kafka elasticity and cost
- Users needing higher performance from MQTT Broker
- Users concerned about RabbitMQ network partitions and performance
may choose RobustMQ as an alternative to their current solution.
Development Path from 0 to 1
Facing such a technically challenging and ambitious project, how do we achieve cold start? How do we drive RobustMQ from 0 to 1?
From a product perspective, we have planned a clear phased development path:
Phase 1: Technical Foundation
In this phase, RobustMQ's users are the developers themselves. The development team, driven by technical pursuit and open-source enthusiasm, gains satisfaction from the project — through learning Rust, distributed storage, and increasing open-source influence — and completes RobustMQ's overall architecture design and basic implementation.
Phase 2: MQTT Protocol Breakthrough
In this phase, RobustMQ's target users are those who need MQTT. We chose MQTT as the entry point for these reasons:
1. Technical Feasibility
The MQTT protocol is relatively lightweight and concise with clear functionality. It is the fastest path to implementing a complete Broker and demonstrating differentiated advantages, enabling quick validation of RobustMQ's real value.
2. Market Gap
The industry currently lacks open-source MQTT Broker solutions with particularly strong performance and architecture.
3. Market Opportunity
After EMQX moved to a commercial license, the open-source community needs an excellent alternative.
Phase 3: Multi-Protocol Ecosystem
In this phase, RobustMQ will serve all target user groups mentioned above. By gradually adapting and completing multiple protocols (Kafka, AMQP, etc.), we will expand use cases and ultimately realize our technical vision.
Currently, we have completed Phase 1 and entered Phase 2. MQTT protocol core functionality is largely complete, and we are moving toward Phase 3. From a product perspective, we have built RobustMQ into a sustainable, viable project.
Why We Insist on Open Source
We have been asked whether we plan to commercialize. Our answer has always been: No. Our goal has always been to become an Apache top-level project.
The reason is that RobustMQ is a technically challenging, ambitious project. If we positioned it as a commercial product from the start, we would likely fail to do it well. Commercial thinking distorts technical decisions, causing choices to serve short-term business goals rather than long-term technical value.
Infrastructure software requires sustained refinement, accumulation, correction, and optimization. Under commercial pressure, this necessary technical accumulation can become distorted and rush toward short-term gains.
We firmly believe that only by remaining 100% open source can RobustMQ truly realize its technical value and achieve long-term success.
Summary
From a product perspective, RobustMQ is positioned as a standard enterprise-grade message queue product. Its core value lies in surpassing existing products through systematic technical optimization across performance, stability, elasticity, cost, and other dimensions, serving as an improved alternative to existing message queues.
RobustMQ is not "yet another message queue" — it is "a better message queue."
Infrastructure software is a long journey. We believe that only by embracing open source, embracing passion, and embracing perseverance can we truly build great infrastructure software. We continue to explore and adjust. We look forward to the day when we can confidently say: RobustMQ is something truly valuable.