NATS explained: how Synadia’s messaging protocol replaces Kafka

NATS beats the old brokers on speed

NATS JetStream reaches 400,000 messages per second on standardized 4 vCPU, 8GB RAM VPS configurations. I find this speed much more reliable than RabbitMQ, which reaches 50,000 to 100,000 messages per second. Kafka moves more volume, reaching 500,000 to over 1,000,000 messages per second, but it introduces higher latency because of batching and replication.

The latency gap is massive.

NATS processes messages in-memory with sub-millisecond latency. In contrast, Kafka latencies range from 10 to 50 milliseconds. RabbitMQ latencies stay between 5 and 20 milliseconds. Moving a 50-service cluster from RabbitMQ to NATS can result in p99 latency dropping from 150 ms to 40 ms while reducing weekly operational overhead from several hours to under one hour. During bursts, NATS processes messages within seconds, whereas RabbitMQ queues lagged for minutes.

RabbitMQ is feature-heavy.

RabbitMQ provides many broker-managed mechanisms, including multiple protocols and complex routing through exchanges and bindings. NATS uses subject-based addressing with wildcards. I find that NATS is much easier to reason about for microservices. NATS Core includes request-reply and queue groups for load-balanced messaging.

Scalability without the partition headache

I prefer NATS because it avoids the partition-based scaling used by Kafka. Kafka scales through partitions, which requires rebalancing and can cause disruption when you increase throughput. NATS scales by adding more workers to a consumer.

JetStream handles the persistence.

JetStream adds a durable log to the core NATS protocol. It supports at-least-once and exactly-once delivery through consumer acknowledgment, deduplication, and idempotent replay. NATS JetStream uses sequence numbers for tracking, while Kafka uses offsets. Every message in a NATS stream is independent. NATS JetStream provides high availability through RAFT consensus, allowing for stream replicas to be configured on a per-stream basis for distributed environments.

You know that low latency is a requirement for microservices.

I recommend pull consumers. Pull consumers let you control the batch size and the pace of message fetching. This is a major advantage over legacy push consumers, which can cause slow consumer problems when the server pushes messages too fast. JetStream handles message deletion via retention policies. You can use limits-based retention, interest-based retention, or work-queue retention.

Deployment on Kubernetes

NATS deployment on Kubernetes is simple because the NATS Helm chart installs a StatefulSet to provide each pod with a stable name, a stable network identity, and a stable volume across restarts. This is necessary because each NATS node owns a slice of the stream on its own disk. The NACK controller allows operators to declare streams as Custom Resource Definitions. The binary is 17 MB.

NATS is tiny.

The NATS server is a single binary with no external runtime dependencies. RabbitMQ requires a compatible version of Erlang on every machine. Kafka requires a JVM and often Zookeeper. A development NATS instance uses only 1 vCPU and 1GB of RAM. Kafka production clusters require at least 8 vCPU and 16GB of RAM.

Do you actually need the heavy overhead of a Kafka cluster?

Synadia Cloud offers various plans for NATS. The Personal plan is free and provides 10 connections and 10 GiB of network data. The Starter plan costs $49 per month and provides 100 connections and 100 GiB of network data. The Pro plan is $199 per month and provides 1,000 connections and 1 TiB of network data.