Learn NATS - History, Background & Why You Need NATS

#Introduction

Episode 0 made sure your environment is ready. Now it's time to understand why NATS exists. This episode 1 answers three big questions: where NATS comes from, what problems it solves, and why you — as an engineer building microservices or event-driven systems — need it.

Many people start using NATS because of tutorials, but understanding its background is far more valuable. By knowing the problems it solves, you'll find it easier to decide when to use NATS, when not to, and how to position it in your architecture. Let's start from the beginning of the story.

#The History of NATS

#Born from Derek Collison

NATS was created by Derek Collison around 2011 while he was working at Apcera. His background is no coincidence: Collison is a veteran of messaging and cloud infrastructure, and he saw that the messaging brokers of the time were too heavy, too complex, and hard to scale. He designed a system that was the opposite: extremely lightweight, extremely fast, and extremely simple.

The name "NATS" itself is borrowed from a linguistic innovation by Noam Chomsky — NATS stands for Neural Autonomic Transport System. From the start, the design was shaped so the broker could be "intelligently silent": don't store anything, don't over-engineer, just deliver messages as fast as possible.

#Core NATS, then JetStream

NATS's journey is divided into two big eras:

Core NATS was designed to be so lightweight that it doesn't store any messages. JetStream, born in 2020, added a file-based persistence layer directly into the server, so NATS gets durable streaming without needing a separate component.

#CNCF Graduated Status

NATS is one of the projects that achieved graduated status at the Cloud Native Computing Foundation (CNCF) — the highest maturity level for open-source projects. That means: healthy governance, an active community, and a technology proven in production by many companies. Active development takes place at nats.io and on GitHub under the nats-io organization.

which nats-server && nats-server -v

If nats-server -v shows version 2.14.x, you're already on the latest version that will be discussed in episode 20.

#Problems NATS Solves

#Extremely Lightweight and Resource-Efficient

The first problem NATS solves is weight. A single nats-server binary is about 15 MB with a small memory footprint — enough to run on a Raspberry Pi or edge devices. Compare that with modern brokers that need hundreds of MB of RAM and complex cluster configuration just to get started.

nats-server    ~15 MB binary, single process
apache-kafka   requires broker + zookeeper/kraft, JVM heavy
rabbitmq       Erlang/OTP runtime, hundreds of MB memory

Lightweight doesn't mean weak: NATS can still process millions of messages per second with millisecond latency, which we'll benchmark in episode 16.

#Simplicity: Subjects Without Complex Configuration

The second problem is complexity. In NATS, routing is done through subjects — dot-separated strings like orders.created — without needing topics, partitions, or complicated queue configuration. A publisher simply sends to a subject, and a subscriber simply listens on that subject.

A single NATS server already supports three communication patterns at once: publish/subscribe, request-reply, and queue groups. There's no separate component for each pattern. This is the simplicity that few other brokers have.

#High Throughput with At-Least-Once

The third problem is delivery guarantees. Core NATS provides very fast at-most-once; JetStream adds at-least-once through acknowledgment and redelivery. On top of that, NATS provides a built-in KV store and object store, so your application data doesn't need to move to another system.

Delivered once vs possibly repeated

core_nats   = "publish once, delivered at most once"
jetstream   = "publish once, guaranteed at least once with ack"
kv_store    = "key-value storage with history and TTL"

The jetstream model above is the backbone for workloads that can't afford to lose messages — and will be a major theme starting in episode 7.

#NATS vs Other Approaches

#Position in the Messaging Market

NATS is not alone. As an initial orientation, here's a quick map that will be covered in full in episode 22:

• Kafka: stateful streaming, partitions, replay, but heavy and complex.
• RabbitMQ: rich exchange-based routing, but a large memory footprint.
• MQTT: lightweight IoT protocol, suited for constrained devices; NATS can also act as an MQTT broker.
• Redis Streams: streaming inside the familiar Redis, but without JetStream features like distributed durability.

lightweight, simple, fast            heavy, stateful, complex
nats ------------------------------ kafka
        mqtt      redis-streams        rabbitmq

The nats position is at the left end of the spectrum: choosing NATS means prioritizing simplicity, speed, and resource efficiency — while still providing JetStream when persistence is needed.

#Conclusion

Episode 1 gave you the context: NATS was born from Derek Collison's hands in 2011 as an answer to the complexity of messaging brokers, evolved from Core NATS to JetStream, and is now a CNCF graduated project developed at nats.io. It solves three big problems: light weight, routing complexity, and the need for at-least-once with built-in persistence.

Key takeaways:

• NATS was created by Derek Collison around 2011 with a lightweight, simple, and fast philosophy.
• Core NATS is pure publish/subscribe without persistence; JetStream added it in 2020.
• NATS has CNCF graduated status with active development at nats.io.
• A single ~15 MB binary is enough for edge devices and Raspberry Pi.
• Subjects handle routing without complex configuration; three communication patterns in one server.
• NATS provides at-least-once, KV store, and object store built-in.

In episode 2 next, we'll discuss core concepts and main architecture — how subjects work behind the scenes, the role of wildcards in routing, the communication patterns of publish/subscribe, request-reply, and queue groups, and NATS components such as nats-server, the nats CLI, client libraries, and nats-box. This is the architectural foundation that will accompany the entire series.