NATS is a simple, high-performance messaging system originally created by Derek Collison, now a CNCF project. It's designed around one core philosophy: messaging should be simple, fast, and secure — not complicated.

Core Concepts

Publish/Subscribe model

The basic unit of communication is the subject (like a topic). Publishers send messages to a subject; subscribers listen on that subject.

Publisher --> "orders.new" --> Subscriber(s)

Subjects support wildcards:

• * matches one token: orders.* matches orders.new, orders.cancelled
• * matches everything after: orders.> matches orders.new.us, orders.new.eu.priority, etc.

Core NATS vs JetStream

This is the most important distinction to understand:

Core NATSJetStreamDeliveryFire-and-forget, at-most-oncePersistent, at-least-once (or exactly-once)StorageNone (in-memory transit only)Disk/memory-backed streamsUse caseReal-time, low-latency messagingDurable messaging, replay, work queuesIf no subscriber listeningMessage is lostMessage is stored and can be consumed later

Core NATS is extremely fast because it does no persistence — it's just routing bytes. JetStream, added later, layers persistence and stream semantics on top (similar in spirit to Kafka) while keeping the same subject-based addressing.

Messaging Patterns NATS Supports

1. Publish/Subscribe — one-to-many broadcast
2. Request/Reply — a built-in pattern where the publisher gets an inbox subject auto-generated, and the responder replies to it. Great for RPC-style calls.
3. Queue Groups — multiple subscribers join a named queue group on the same subject; only one member of the group gets each message. This gives you load-balanced consumers without extra infrastructure.
4. Streams & Consumers (JetStream) — persistent, ordered logs of messages that consumers can replay, ack, or process at their own pace.

Why People Choose NATS

• Simplicity — a single small binary (nats-server), minimal configuration to get started
• Performance — very low latency, millions of messages/sec on modest hardware
• Built-in clustering & mesh gossip — servers auto-discover and form clusters
• Multi-tenancy — accounts and subjects provide isolation without spinning up separate infra
• Client libraries in nearly every language (Go, Python, JS, Java, Rust, etc.)
• Edge-friendly — small footprint means it runs well on IoT/edge devices, not just data centers

Comparison to Alternatives

• vs Kafka: Kafka is heavier, disk-log-centric, and optimized for huge-scale event streaming with strong ordering guarantees per partition. NATS is lighter-weight and simpler to operate, with JetStream now covering much of the same persistence use case but with less operational overhead.
• vs RabbitMQ: RabbitMQ is a full-featured broker with complex routing (exchanges, bindings) and strong AMQP semantics. NATS trades some of that routing complexity for simplicity and speed, using subject wildcards instead of complex exchange types.
• vs MQTT: MQTT is purpose-built for IoT with QoS levels; NATS is more general-purpose but works well in similar constrained environments (and NATS even has an MQTT-compatible mode).

A Minimal Example (conceptual)

# Subscriber
nats sub "orders.>"


# Publisher
nats pub "orders.new" "Order #1234 placed"

With JetStream, you'd first create a stream to capture the subjects durably, then create a consumer to read from it — consumers can be push-based (server sends messages) or pull-based (client requests batches).