NATS replaces legacy messaging for microservices

NATS provides a lightweight alternative to Kafka and RabbitMQ for distributed systems. Core NATS handles high-speed, fire-and-forget messaging through a subject-based routing system that avoids the overhead of traditional queues. NATS Core provides at-most-once delivery, but JetStream enables at-least-once and exactly-once guarantees. You can use NATS for request-reply patterns or simple publish-subscribe workflows. JetStream acts as the persistence layer by adding durability and the ability to replay messages for various use cases. While Kafka focuses on high-volume data pipelines with heavy partitions, JetStream allows users to manage streams through simple subject filtering. It provides exactly-once delivery through message ID deduplication to ensure reliability.

NATS uses a subject-based addressing system instead of IP addresses or DNS. This approach allows for location-independent communication across a global mesh. You can connect to a NATS server and talk to any other connected entity via simple subjects. This architecture supports many-to-many communication patterns efficiently. The architecture enables load balancing because the server intelligently routes messages to the closest responder. Users utilize pull consumer priority groups to control message overflow when clients fail to keep up with demand. Unlike RabbitMQ, which acts like a postal system, NATS functions like a switchboard. NATS provides around 40 different client implementations, including eight official languages, to ensure reliability.

Performance and scaling

NATS delivers superior latency for real-time workloads. Core NATS reaches throughputs of 3 to 11 million messages per second. JetStream throughput reaches 800,000 messages per second while providing persistence. In contrast, Kafka handles millions of records per second but introduces higher latency due to its batching and compression models. For microservices teams, NATS delivers microsecond-to-millisecond latency. You will find the scale easier to manage because you just add more workers to a consumer instead of repartitioning a cluster. NATS scales horizontally by allowing multiple clients to pull from a single consumer, which means adding more workers increases throughput without the complex repartitioning or rebalancing disruptions that plague Kafka deployments.

JetStream replaces Kafka by providing retention policies like max message count, max bytes, and max age. It also allows interest-based retention where a message stays until every consumer with registered interest acknowledges it. This capability helps with work queues where a message disappears immediately after acknowledgment. JetStream consumers can start from different points using DeliverAll, DeliverNew, or DeliverLast. Consumers can also use Fetch(n) to request specific amounts or Consume to use a continuous callback. This provides a direct equivalent to the Kafka poll loop. NATS handles message ordering within its streams, providing a flexible alternative to Kafka’s partition-based ordering.

Synadia funded 97% of the NATS server contributions, which led to a dispute regarding its open-source status when they proposed moving to a Business Source License.

Operational deployment

Kubernetes users should use the official NATS Helm chart for deployment. This method manages all necessary resources and provides a production-tested setup. The NATS community no longer recommends the NATS Operator for new deployments. Does the current licensing agreement between Synadia and the CNCF provide enough long-term stability for the project? Synadia and the CNCF reached an agreement on May 1st, where Synadia transfers the NATS trademark to the Linux Foundation to provide stability.