RobustMQ vs NATS: Memory Mode
While designing RobustMQ, we kept asking: Can one unified architecture serve everything from persistent storage to in-memory, from strong consistency to eventual consistency?
NATS excels in microservice messaging, real-time push, IoT, and similar scenarios. Its strengths are pure memory, ultra-low latency, and very high QPS. But NATS does memory distribution only; for persistence you switch to JetStream, which is a separate system. We want RobustMQ to handle scenarios from NATS to Kafka on a single platform, with simple configuration.
Memory mode is designed for that.
Target Scenarios for Memory Mode
RobustMQ's memory mode mainly targets three scenario types.
Real-time market data push. Stock prices, crypto quotes, forex rates—these are high-frequency updates, latency-sensitive, with low historical value. New prices overwrite old ones; losing a few seconds of history on restart is acceptable, clients can resubscribe. But if latency goes from microseconds to milliseconds, users notice. This fits memory storage well.
Sensor data sampling. IoT devices may report thousands of samples per second, but not every point needs precise storage. Systems care about trends and anomalies; occasional loss of a few points is fine. And persisting massive sensor data is expensive. Memory mode plus downsampling keeps latency low and cost under control.
Transient state in games. Player positions, temporary buffs, skill cooldowns—these have short lifecycles; if lost, clients resync. But latency matters a lot because it affects gameplay. Critical data (gold, inventory, level) goes through the database; the message queue handles transient state in real time.
These scenarios share a trait: they tolerate some data loss but are very latency-sensitive. NATS targets exactly this; RobustMQ's memory mode does too.
Single Replica vs Dual Replica
NATS Core is pure memory, single replica—restart and all data is gone. That's enough for many cases, but some want a balance between low latency and reliability.
Single-replica memory loses all unconsumed data on restart or failure. Even when loss is acceptable, reducing that risk helps. For example, a game server restart that drops all player positions forces every client to resend, causing brief chaos.
Dual-replica memory with weak consistency (acks=1) addresses this. On write, the Leader returns success immediately—latency stays in microseconds. In the background it asynchronously replicates to a second replica. Data is lost only if both replicas fail, which is much rarer. On single-node restart, the other replica still has data and can serve.
This is still not strong consistency: if the Leader crashes right after returning success and before replicating, data can be lost. But compared to single replica, reliability is much better. Compared to tri-replica persistence, latency is far better (100µs vs ~5ms). A practical compromise between latency and reliability.
Usage
RobustMQ's memory mode is easy to use. When creating a Shard, set storage type to memory and replica count, and you're done. No extra config, no new components, minimal friction for users.
In one cluster, some Shards can use memory mode (market data) and others persistent mode (order messages). Users configure per business needs. A unified platform keeps operations simple—no need to run multiple systems.
Memory and persistent modes can switch seamlessly. If a topic goes from "loss okay" to "must not lose," change the config; new Shards use persistence, and history migrates gradually. The transition is smooth.
Memory Capacity Management
Memory is limited. RobustMQ manages it with capacity and time limits. For example: max 1GB per Segment, or max 5 minutes retention. When a threshold is hit, the Segment is sealed and a new one created. When memory is full, options are to reject new writes or evict the oldest data.
For sealed memory Segments, if async persistence is configured, they can be written to disk or S3 in the background and then freed. That keeps write latency low, avoids unbounded memory growth, and gives some data durability.
Performance Expectations
For memory mode we expect: single-replica latency ~100µs, dual-replica ~100–200µs (async replication doesn’t block the response), throughput in the millions of msg/sec. That matches or exceeds NATS while offering better reliability via dual replica.
Compared to persistent mode at 3–5ms, memory mode is about 20–50x faster. For real-time markets, game state, and similar workloads, that difference matters.
Differences from NATS
NATS is a dedicated in-memory messaging system—lightweight and focused. RobustMQ's memory mode is one mode in a unified platform, enabled by configuration.
The advantage is flexibility. One RobustMQ cluster can serve both persistent and in-memory workloads. No need for two systems or switching between NATS and Kafka. If requirements change, adjust config rather than migrate.
Another advantage is the dual-replica option. NATS Core is single replica; JetStream is persistent; there's no middle ground. RobustMQ offers dual-replica memory, giving more choices between latency and reliability.
Summary
RobustMQ's memory mode isn't competing with NATS; it brings NATS-like capabilities into a unified platform. By configuring storage type and replica count at the Shard level, users can choose: single-replica memory for lowest latency, dual-replica for reliability, or persistence where loss is unacceptable.
One platform, multiple modes, configured as needed. That's how we express storage flexibility in RobustMQ.
About RobustMQ
RobustMQ is a high-performance message queue written in Rust with compute-storage separation and support for multiple storage modes from memory to persistent. Follow us on GitHub and join the technical discussion.