What is Nats?

A process listening on a port.

Everyone is familiar with the Http server. It's just a process running on a machine. It binds to a port (usually 80 or 443), accepts connections, and speaks a protocol: Http.

A client connects, sends a request, gets a response. That's the whole model. Under the hood, it's all built on Tcp—Transmission Control Protocol handles the reliable delivery so the application doesn't have to.

This is the mental model to hold onto: a server is just a process, listening on a port, speaking a protocol over Tcp.

A server that listens on Tcp.

At its core, Nats is a process—just like an Http server. It binds to a Tcp port, accepts connections, and routes messages. Nothing exotic about that.

Where an Http server listens on port 80 and speaks Http, a Nats server listens on port 4222 and speaks the Nats protocol. Clients connect via Tcp, send messages, and receive messages. No magic, no special infrastructure—just a process on your machine.

A simple foundation—a single binary speaking a simple protocol over Tcp.

Client asks. Server answers. That's the whole protocol.

Http does exactly one thing: a client sends a request to a specific server, and the server responds. Everything else—push notifications, streaming, fan-out—is bolted on after the fact.

Better protocols don't change the model underneath.

Each one improves something—encoding, query flexibility, full-duplex—but none of them introduce native many-to-many messaging. Every connection is still one client talking to one server.

Built for reliability. Not for millions of messages per second.

Tcp handles a lot for you—retransmissions, congestion control, ordered delivery. The kernel takes care of it so your application doesn't have to.

But Tcp was designed before anyone imagined moving millions of messages per second. At that scale, its “helpful” features start working against you.

Reliable. Ordered. But not built for millions of messages per second. These aren't bugs—they're trade-offs from a protocol designed before high-throughput messaging existed.

The Nats protocol is human-readable text over Tcp—you can debug it with telnet.

But Nats doesn't just speak text over Tcp. It takes control.

Tcp's trade-offs at scale—head-of-line blocking, unpredictable buffering, slow failure detection—don't go away just because you have a nice protocol on top. Nats handles them explicitly:

The foundational data communication layer for distributed systems

Core is the foundational layer that everything else in the Nats ecosystem builds on. At its heart is publish/subscribe—fire-and-forget messaging where any publisher can reach any subscriber through named subjects.

Publishers and subscribers never need to know where each other are.

In Nats, you don't send messages to servers, IPs, or endpoints — you publish to subjects. A subject is just a string like orders.us.east. No admin CLI, no partition count, no pre-creation. Publish to it and it exists. Subscribers express interest in subjects, and Nats routes messages to them — regardless of where they are in the network.

The dot separator creates a natural hierarchy, and wildcards let subscribers listen to entire categories of messages without knowing every specific subject:

Many-to-many, not point-to-point.

Publishers send to subjects. Any number of subscribers can listen. Adding a new consumer is a one-line change in the consumer—publishers don't even know. No producer modifications, no coordination, no redeployment.

Fire-and-forget messaging.

Publish a message and Nats delivers it to all matching subscribers immediately. No disk writes. No acknowledgments. No broker consensus. Just memory-to-memory transfer.

This is at-most-once delivery—and that's a deliberate design choice, not a limitation. For real-time data—telemetry, metrics, live updates—you want the latest value, not a queue of stale ones. No redelivery storms, no message pile-ups. The system stays stable under failure.

RPC without the service mesh.

Need a response? Nats creates a unique inbox subject for each request. Responders publish to that inbox, and only you receive the reply. No sidecars, no Envoy config, no Istio—just pub/sub with a clever addressing trick. Send one request and collect multiple replies (scatter-gather) to find the fastest responder or aggregate results from shards. No response? The request times out cleanly—unlike Http hanging connections, failed services don't cascade into client-side thread exhaustion.

Instant failure feedback, not silent timeouts.

With Http, if a service is down your request hangs until a timeout fires—30 seconds of wasted time and a blocked thread. Nats knows the subscription table. If nobody is listening on a subject, the server tells you immediately with a no responders status. No guessing, no waiting, no cascading failures from accumulated hanging connections.

Scaling without Kubernetes.

Add a queue group name to your subscription and Nats distributes messages across all subscribers in that group. No coordinator, no leader election, no split-brain scenarios.

Exactly one subscriber — each message goes to one subscriber in the group. Start a new worker and it gets messages immediately—stop one and others pick up instantly. No partition rebalancing delay.

Load balance — Nats distributes work evenly across workers. Scale from 1 to 1000 processes with zero configuration changes.

Fanning out — queue groups and regular subscribers coexist on the same subject. Load balance to workers while simultaneously sending to monitoring and analytics.

Every messaging system has the same Achilles' heel.

A message broker sits between producers and consumers, holding messages in memory until they're delivered. This works beautifully—until something goes wrong.

What if a consumer crashes? Messages queue up. What if the broker itself crashes? Everything in memory vanishes. This isn't a bug in any particular system—it's a fundamental tension in distributed messaging.

Still fast. Now durable.

Core is fire-and-forget. If no one is listening when a message is published, it vanishes. Jetstream adds persistence on top—same protocol, same subjects, but messages are stored and can be replayed.

Publish now, consume later.

Jetstream offers a durability spectrum. More durability means more work per message—pick the right trade-off per stream.

Memory — fastest. Messages live in RAM and are lost on restart. Ideal for caches and ephemeral state.

Disk — durable. Messages survive server restarts. The default for most workloads.

Replicated — safest. Messages are written to multiple servers. Survives machine failures with no data loss.

Persistence enables temporal decoupling. Subscribers can go offline, come back, and catch up on missed messages automatically.

Append-only logs that capture messages by subject.

A stream is an append-only log bound to one or more subjects. Every matching message is stored in sequence. Retention policy controls when messages leave the log:

Limits-based — cap by max messages, max bytes, or max age. Oldest messages are discarded when limits are hit.

Interest-based — keep messages until all consumers have seen them. Nothing is discarded while there's still interest.

Work-queue — delete on ack. Each message is processed exactly once, then removed from the stream.

Durable cursors that track delivery progress.

Consumers act as durable cursors, tracking delivery progress independently. Messages redeliver until acknowledged, guaranteeing at-least-once delivery. For critical paths, idempotent publishing with message deduplication provides exactly-once semantics. When a consumer disconnects, Jetstream remembers its position. On reconnect, missed messages replay automatically.

Most platforms cover one or two of these well, but not all three. Message brokers add key-value APIs as an afterthought. Key-value stores bolt on pub/sub. Nobody covers all three over a single protocol.

Nats does. A key-value pair is just a subject with the latest message retained. A large file is a sequence of chunked messages in a stream. Same protocol, same connection, same replication—no new infrastructure.

Key-value storage over your existing Nats connection.

Nats Key Value is a key-value store built on top of Jetstream. Get, put, delete, and watch keys—all over your existing Nats connection.

Every Key Value bucket is backed by a Jetstream stream. Keys map to subjects, values to message payloads, and revisions to sequence numbers. A put("user.123.name", "Alice") becomes a publish to $KV.users.user.123.name. Watchers are just Jetstream consumers with subject filters.

Watch — subscribe to key patterns like user.123.> and get notified on every change in real-time. No polling. Build reactive UIs, configuration hot-reload, or distributed coordination.

TTL — keys expire automatically after a configured duration. Clean up stale state without manual intervention.

History — retain previous values per key with atomic compare-and-swap for safe concurrent updates.

Large blob storage over Nats.

Store files, images, ML models—anything up to gigabytes. Nats automatically chunks large objects into Jetstream messages, handles replication across the cluster, and reassembles them on read. Like S3, but without the separate service.

Each object is split into fixed-size chunks (default 128 KB) and published to a dedicated Jetstream stream. Metadata—name, size, content type, checksum—is stored in a companion stream. On read, the client fetches chunks in order and verifies the checksum.

Watch for changes — subscribe to object updates just like Key Value watchers. Get notified when a model is updated, a config file changes, or a new artifact is published.

Replicated — inherits Jetstream replication. Configure R=3 and your objects survive server failures. No need for a separate distributed file system.

Connect anywhere, reach everywhere.

Nats servers form clusters so your code doesn't change whether subscribers are local, in another region, or on the edge—the network figures it out. Interest-based routing means messages only flow where subscribers exist—Nats doesn't copy data to regions with no listeners, so bandwidth is automatically optimized.

Leaf nodes — extend Nats to the edge via a 20MB binary that runs on a Raspberry Pi—factories, stores, vehicles, anywhere with intermittent connectivity. Messages queue locally during outages.

Clusters — a group of Nats servers that share clients and messages. They form a full mesh automatically—publish to any node, subscribers on any other node receive it.

Superclusters — connect multiple clusters via gateway connections for global reach. Each cluster operates independently, but messages route seamlessly across all of them.

Extend Nats to the edge—factories, stores, vehicles, anywhere.

Single upstream connection — a standalone Nats server (20MB binary) connects to a cluster. Runs on a Raspberry Pi, an industrial gateway, or a vehicle's onboard computer—anywhere a full cluster member would be overkill.

Subject filtering — control exactly which subjects bridge between the leaf and the upstream cluster. A factory floor node might only sync sensors.> upstream while keeping local traffic private. Only the data you choose leaves the edge.

Resilient at the edge — when the upstream connection drops, the leaf node keeps running. Local publishers and subscribers continue communicating. With Jetstream enabled, messages destined for the cluster queue until connectivity is restored—no data loss, no application changes.

Full-mesh routes within a region—every server can reach every subscriber.

Full-mesh route connections — every server maintains a direct Tcp link to every other server in the cluster. Publish to any server, and it reaches all subscribers regardless of which server they're connected to.

Auto-discovery — point a new server at any existing member and it learns the full topology. No static config files listing every node. If one goes down, clients automatically reconnect to a surviving member.

Transparent failover — clients connect to multiple servers and failover automatically. No connection pooling libraries, no retry logic to write, no circuit breakers to configure—the client library handles it.

How Jetstream keeps streams consistent across a cluster

One Raft group per stream — Jetstream runs a separate Raft consensus group for each stream and each consumer. No single leader bottleneck—each group elects its own leader independently.

Meta group for placement — a cluster-wide meta group (all Jetstream-enabled servers) decides where to place new streams and consumers. Each stream group then handles its own data replication; each consumer group tracks delivery state.

Quorum writes — a message is only acknowledged once a majority of replicas have written it. With R3, that means 2 of 3 servers must confirm before the publisher gets an ACK.

Gateways between regions—global reach without full-mesh overhead.

Gateway connections — each cluster elects a gateway pair that maintains a single logical link to every other cluster. No full-mesh between regions—just targeted hops.

Interest-based routing — messages only traverse gateways when subscribers exist in the remote region. Publish orders.us.east in New York and nobody in Frankfurt is listening? The message never leaves the US cluster.

Accounts and security boundaries are shared across the supercluster, so a service in any region can reach any other service on the same account—same subjects, same permissions, no extra configuration per region.

Secure by default, decentralized by design.

TLS encryption is a flag away. Accounts are isolated by default—multi-tenant by design, messages in one account are invisible to others, shared only through explicit exports/imports. Auth scales from simple credentials to fully decentralized identity:

Tokens — a single shared secret string. The simplest option for development and internal services.

Username/Password — familiar credentials with optional bcrypt hashing. Easy to set up, easy to reason about.

NKeys — Ed25519 key pairs where the server stores only public keys—private keys never leave the client. Nothing valuable to steal.

Decentralized JWTs — account operators issue credentials without touching server config. Add users, revoke access, change permissions with no server restart and no config file edits.

Auth Callout — delegate authentication to your own external service. Plug in LDAP, OAuth2, or any custom identity provider without forking the server.

Your auth rules. Nats enforcement.

NKeys and JWTs handle most scenarios, but what if credentials already live in an LDAP directory, an OAuth provider, or a custom database?

Auth Callout — lets Nats delegate authentication to your own service—a regular Nats subscriber that receives connection requests, validates credentials against any backend, and returns a signed JWT with scoped permissions.

The callout service subscribes to $SYS.REQ.USER.AUTH. When a client connects, Nats publishes the connection details to that subject. Your service validates, builds a user JWT, signs it, and replies. Nats enforces the permissions—your service owns the decision.

Before diving into the details, here's what each system gives you out of the box.

How each system talks on the wire, names its destinations, and layers on persistence.

The protocol shapes everything else—how easy it is to debug, how fast you can onboard, and how much ceremony stands between you and your first message. Compare the foundations.

Every messaging system claims pub/sub. Few give you the rest without extra infrastructure.

Pub/sub, request/reply, queue groups, and back-pressure are the building blocks of real-time messaging. See how Nats handles each one natively, while alternatives require workarounds, extra components, or manual plumbing.

Jetstream isn't the first persistent streaming system. But it's the only one that isn't a separate system.

Kafka, Pulsar, and RabbitMQ Streams were built for durable streaming too. The difference is in what else they bring along: separate protocols, separate clusters, separate operational burdens. Jetstream is a capability you turn on inside the Nats server you already run.

Running at scale means clustering, security, and multi-tenancy. Nats builds all three into the server.

Clustering shouldn't require a coordinator service. Auth shouldn't require an external system. Multi-tenancy shouldn't be a naming convention. See how Nats handles operations and security compared to the alternatives.

Start simple. Layer on capabilities as your needs grow.

Nats gives you a toolkit of capabilities that share one subject namespace, one connection, and one security model. Most applications start with Core and add capabilities only when needed. Security wraps everything—enable it at any point, and it applies across all layers.