Some Thoughts on RobustMQ in Edge Scenarios
I've been thinking about RobustMQ's fit and role in edge scenarios. We're not saying we must become an edge platform—rather, we want to understand: given RobustMQ's design principles and architecture, what can it do at the edge? Where could it add value?
I'll be honest: my understanding of edge computing is still limited. This article is based on our preliminary research and assumptions, exploring where RobustMQ might fit in the edge ecosystem. These thoughts may be incomplete or off; we welcome discussion and corrections.
Edge Message Queue vs Edge Data Processing Platform
Before going deep on edge, we need to distinguish edge message queues from edge data processing platforms.
An edge message queue focuses on: lightweight deployment, receiving messages, local caching, reliable forwarding to the cloud, and support for edge protocols. Its role is clear: message transport infrastructure.
An edge data processing platform is much broader. Beyond a message queue, it includes rules engines (aggregation, filtering), protocol gateways (Modbus, OPC UA), edge compute frameworks (AI inference, serverless), and device management. It's a full solution from device onboarding to processing to cloud sync.
Look at existing products. EMQ X Edge is more than an MQTT Broker—it has rules and data bridging. AWS IoT Greengrass is effectively an edge OS with container runtime, Lambda, message routing, device management. Azure IoT Edge is similar. None are just message queues; they're edge data processing platforms.
RobustMQ should position as an edge message queue, not an edge data processing platform. That's partly about responsibility and partly about focus. We'll do the core message queue well instead of spreading too thin.
What We Think Edge Actually Needs
We don't know edge deeply yet, but from our research we see some common needs.
Data aggregation. Devices produce massive raw data; sending everything up isn't practical. A factory floor might have 1,000 sensors, 10K messages per second, ~10MB/s raw. With edge aggregation—e.g., per-second averages and filtering of normal ranges—you might send only 100 aggregated messages plus anomalies, cutting data 100x. That saves bandwidth and eases cloud load.
Network conditions. Edge networks are often unstable. Factories, retail stores, vehicles—network quality is worse than data centers. Direct device-to-cloud suffers from jitter and disconnects. The edge needs buffering and local autonomy.
Real-time coordination. Devices need to coordinate in real time. Round-tripping through the cloud adds too much latency. For example, factory line devices must respond in milliseconds. Communication must happen locally, not via the cloud.
Resource limits. Edge devices are typically small boxes or industrial PCs; they can't run heavy distributed systems. Binaries must be small, dependencies minimal, memory footprint low.
If this doesn’t match reality, please let us know. We're still learning.
Composable Architecture
Given these needs, the question becomes: who does aggregation and processing?
Our view: RobustMQ provides the message queue; users or other tools do the processing.
An edge solution should be composable. Devices connect via a protocol gateway (e.g., open-source Neuron) and convert to MQTT. Data enters RobustMQ for local caching. User logic subscribes to raw data topics, runs aggregation/filtering/computation, and writes results to another topic. RobustMQ's cloud Connector subscribes to the processed data and reliably syncs to the cloud.
Key point: RobustMQ handles message flow; processing logic is user-defined. Users can use Python, Go, Rust, any language and libraries, with full control. RobustMQ doesn’t constrain them or bundle a "rules engine" framework.
This is based on our current understanding. If in practice most users want an out-of-the-box rules engine, we may need to revisit. We're treating this as a working hypothesis, not a final answer.
Why This Direction
A few principles drive this.
Clear responsibilities. A message queue should focus on messaging. Aggregation and processing are a separate layer and should be decoupled. Clear boundaries make components easier to understand and maintain.
Avoid scope creep. Building rules engines, protocol gateways, edge compute would be a huge effort, and each area already has specialists. We might not do better, and it would distract from our core strengths.
Flexibility. User-written logic can use any language and framework. Rules engines lower the bar but also limit expressiveness; complex logic still needs code. So we give users full control from the start.
Ecosystem integration. Edge already has protocol gateways, AI frameworks, streaming engines. RobustMQ focuses on the message queue and integrates with these instead of reinventing.
Whether this matches reality will need validation from people actually doing edge work.
Value of Lightweight Edge Deployment
Even without a full data platform, lightweight edge deployment has value.
Many edge cases don’t need complex aggregation—only reliable message transport. Retail POS data doesn’t need edge aggregation; cache and upload is enough. But offline caching and retry on reconnect are needed. RobustMQ's RocksDB mode fits: lightweight, persistent, reliable sync.
Other cases need device-to-device communication. Factory device state sync stays local with millisecond latency. No heavy aggregation; just local Pub/Sub.
Some need only edge caching. Device data goes to local RobustMQ; the cloud pulls periodically or batches when the network is free. RobustMQ acts as an edge buffer.
A lightweight message queue has value on its own; it doesn’t have to be a full platform. But we might be wrong; real scenarios may be more complex.
Possible Evolution
Based on current understanding, RobustMQ’s edge path might look like this.
Step 1: Solid edge message queue basics. Single binary, zero dependencies, small package, RocksDB storage. MQTT support. Reliable cloud sync. With that, RobustMQ can serve as the message queue component in edge solutions.
Step 2: Light built-in capabilities. Simple filtering, batching, time-window aggregation—config-driven, no heavy rules engine. Lowers development cost without limiting flexibility.
Step 3: If edge becomes strategic, consider an edge gateway component. That should be a separate component focused on protocol conversion, not baked into the core.
These are hypotheses. Reality may differ; we’ll validate with practice and user feedback.
Summary
RobustMQ’s position in edge computing is edge message queue, not edge data processing platform.
We may provide: lightweight deployment, MQTT support, local caching, reliable cloud sync, device-to-device messaging.
We likely won’t provide: complex rules engines, protocol gateways, edge compute frameworks, device management. These come from the ecosystem.
Composable flow: Protocol gateway (optional, separate) → RobustMQ (message queue) → User logic (custom) → RobustMQ (routing) → Cloud.
These thoughts are based on our limited understanding of edge. Edge computing is complex; real needs may differ from our assumptions. We’re still learning; we welcome input from people with edge experience. We’ll refine these ideas as we learn more.
About RobustMQ
RobustMQ is a high-performance message queue written in Rust with compute-storage separation, supporting both cloud clusters and lightweight edge deployment. We're exploring how to serve different scenarios better. Follow us on GitHub and join the technical discussion.