In the landscape of messaging systems, NATS occupies a unique position: a connective tissue designed from the ground up for cloud-native, edge, and IoT environments. Where Kafka prioritizes durability and RabbitMQ prioritizes flexibility, NATS prioritizes simplicity, performance, and operational efficiency.

Created by Derek Collison (who previously built messaging systems at TIBCO and Apcera), NATS strips messaging to its essence. The core NATS server is a single 15MB binary with zero dependencies, capable of handling millions of messages per second with sub-millisecond latency. It's messaging for environments where complexity is the enemy—distributed systems at the edge, IoT device communication, microservices sidecars, and high-frequency trading systems.

With NATS JetStream, NATS has evolved to include persistence and streaming capabilities while maintaining its lightweight philosophy—making it a compelling alternative for teams who want Kafka-like features without Kafka-like operational overhead.

Core NATS (without JetStream) operates as a "fire-and-forget" messaging system with at-most-once delivery semantics. This design choice enables extreme performance by eliminating acknowledgment overhead.

Key characteristics:

1. No message persistence: Messages exist only in memory; if no subscriber is connected, messages are lost
2. At-most-once delivery: Messages are delivered zero or one time—never duplicated, never retried
3. Pure pub-sub: Publishers broadcast to subjects; subscribers receive if connected
4. Text-based protocol: Simple, human-readable protocol over TCP

This model is ideal for scenarios where message loss is acceptable (telemetry, metrics, heartbeats) or where the application layer handles reliability.

// Go client example - Publisher
nc, _ := nats.Connect("nats://localhost:4222")
nc.Publish("updates.weather.nyc", []byte("Sunny, 72°F"))

// Subscriber
nc.Subscribe("updates.weather.*", func(msg *nats.Msg) {
    fmt.Printf("Received: %s\n", string(msg.Data))
})

Why at-most-once can be the right choice:

The lack of persistence might seem like a limitation, but it's actually a deliberate design for specific use cases:

1. Real-time data where old data is stale: Stock prices, sensor readings—old values are replaced, not accumulated
2. Heartbeats and health checks: Missing one heartbeat is fine; it's the pattern that matters
3. Events triggering cached lookups: The event signals "something changed," receiver fetches current state from source of truth
4. High-frequency trading: Sub-millisecond latency matters more than guaranteed delivery
5. Distributed metrics: Aggregates tolerate occasional missing data points

NATS uses a hierarchical, dot-separated subject addressing scheme that enables powerful topic filtering without broker configuration.

Subject anatomy:

Subjects are case-sensitive strings using tokens separated by dots:

• time.us.east — Three tokens
• orders.new — Two tokens
• metrics.host123.cpu — Three tokens

Wildcards enable flexible subscriptions:

1. Single-token wildcard (*): Matches exactly one token

   • orders.*.shipped matches orders.123.shipped, not orders.shipped

2. Multi-token wildcard (>): Matches one or more tokens at the end

   • orders.> matches orders.new, orders.123.shipped, orders.a.b.c.d

Subject design patterns:

# Hierarchical naming convention
<domain>.<entity>.<event-type>
<system>.<component>.<metric>
<region>.<service>.<action>

# Examples
orders.customer123.created
metrics.webserver01.cpu.load
us-east.payments.transaction.completed

# Subscription patterns
orders.*.created        # All order creations
metrics.webserver*.>    # All metrics from webservers
us-east.payments.>      # All payment events in US-East

No broker configuration required:

Unlike RabbitMQ where you must declare exchanges, bindings, and queues before use, NATS subjects are purely convention. Publishers send to any subject; subscribers listen on any subject. The server routes based on subscriptions without prior configuration. This enables true dynamic messaging where services can appear and disappear without broker coordination.

Beyond pub-sub, NATS excels at request-reply patterns—synchronous-style communication built on asynchronous messaging. This enables RPC-like semantics without point-to-point connections.

How request-reply works:

1. Requester creates a unique reply subject (inbox)
2. Requester sends message with Reply-To header pointing to inbox
3. Responder receives message, sends reply to the inbox
4. Requester receives reply on inbox, optionally with timeout

// Request - blocks waiting for reply (with timeout)
msg, err := nc.Request("service.users.get", 
    []byte(`{"id": "123"}`), 
    2*time.Second)
if err != nil {
    // Timeout or error
}
fmt.Printf("User: %s\n", msg.Data)

// Responder
nc.Subscribe("service.users.get", func(msg *nats.Msg) {
    user := getUserById(msg.Data)
    msg.Respond([]byte(user.ToJSON()))
})

Scatter-gather pattern:

Request-reply can collect responses from multiple responders:

// Send request, collect multiple replies
inbox := nats.NewInbox()
sub, _ := nc.SubscribeSync(inbox)

nc.PublishRequest("service.health.check", inbox, []byte(""))

// Collect responses with timeout
for {
    msg, err := sub.NextMsg(100 * time.Millisecond)
    if err == nats.ErrTimeout {
        break // No more responses
    }
    fmt.Printf("Response from: %s\n", msg.Data)
}

Advantages over HTTP for microservices:

1. Location transparency: Requester doesn't need responder's address
2. Load balancing built-in: When combined with queue groups
3. Timeout handling: Native support for request timeouts
4. Decoupled deployment: Services can move without client changes

Queue groups provide automatic load balancing across subscribers without additional configuration. When multiple subscribers join the same queue group, NATS distributes messages among them—only one member receives each message.

// Three service instances subscribed to same queue group
// Each receives ~1/3 of messages

// Instance 1
nc.QueueSubscribe("orders.process", "order-workers", handler)

// Instance 2
nc.QueueSubscribe("orders.process", "order-workers", handler)

// Instance 3
nc.QueueSubscribe("orders.process", "order-workers", handler)

Queue groups enable competing consumers:

This is NATS's equivalent of a work queue. Each message goes to exactly one subscriber in the group, distributing load automatically.

Combining queue groups with wildcards:

// All order events, distributed across workers
nc.QueueSubscribe("orders.>", "order-processors", handler)

// Each worker processes a fraction of:
// - orders.created
// - orders.updated  
// - orders.shipped
// - orders.cancelled

Queue groups + request-reply:

Combine queue groups with request-reply for load-balanced RPC:

// Multiple service instances form queue group
nc.QueueSubscribe("service.calculate", "calculators", func(msg *nats.Msg) {
    result := expensiveCalculation(msg.Data)
    msg.Respond(result)
})

// Client request goes to ONE calculator
msg, _ := nc.Request("service.calculate", data, timeout)

While core NATS provides at-most-once delivery, NATS JetStream adds:

1. Message persistence: Messages stored to disk, survive restarts
2. At-least-once delivery: Acknowledgments and redelivery
3. Stream processing: Replay from any point in time
4. Exactly-once semantics: Message deduplication

JetStream brings Kafka-like capabilities to NATS while maintaining its operational simplicity.

Creating streams and consumers:

js, _ := nc.JetStream()

// Create a stream (like a Kafka topic)
js.AddStream(&nats.StreamConfig{
    Name:     "ORDERS",
    Subjects: []string{"orders.>"},
    Storage:  nats.FileStorage,
    Replicas: 3,
    Retention: nats.LimitsPolicy,
    MaxMsgs:  1000000,
    MaxAge:   24 * time.Hour,
})

// Publish with acknowledgment
ack, _ := js.Publish("orders.new", orderData)
fmt.Printf("Published to stream seq: %d\n", ack.Sequence)

Consumer types:

// Pull consumer - client controls pace
consumer, _ := js.CreateConsumer("ORDERS", &nats.ConsumerConfig{
    Durable:   "order-processor",
    AckPolicy: nats.AckExplicitPolicy,
})

sub, _ := consumer.Pull(10)  // Pull batch of 10
for _, msg := range sub.Messages() {
    process(msg)
    msg.Ack()  // Explicit acknowledgment
}

// Push consumer - server delivers to subject
js.Subscribe("orders.>", func(msg *nats.Msg) {
    process(msg)
    msg.Ack()
}, nats.Durable("order-handler"))

Replay and temporal queries:

// Replay from beginning of stream
js.Subscribe("orders.>", handler, 
    nats.DeliverAll())

// Replay from specific time
js.Subscribe("orders.>", handler,
    nats.StartTime(time.Now().Add(-1*time.Hour)))

// Replay from sequence number
js.Subscribe("orders.>", handler,
    nats.StartSequence(1000))

NATS offers multiple topology options for different deployment scenarios, from single-node development to global multi-cluster production.

Full mesh clustering:

NATS servers form a full mesh where every server connects to every other server. Messages route automatically across the cluster.

# Server 1 config
cluster {
  listen: 0.0.0.0:6222
  routes: [
    nats://server2:6222
    nats://server3:6222
  ]
}

# Clients connect to any server; messages route automatically
nats://server1:4222  →  Messages reach subscribers on any server

Leaf nodes for edge and hybrid:

Leaf nodes connect to a central cluster without becoming full members. Ideal for:

• Edge locations with limited connectivity
• Security zones requiring isolation
• Extending NATS into cloud/on-prem hybrid

JetStream replication:

For JetStream persistence, configure replication factor:

// Stream replicated across 3 servers
js.AddStream(&nats.StreamConfig{
    Name:     "ORDERS",
    Replicas: 3,  // Raft consensus for durability
    Storage:  nats.FileStorage,
})

Deployment options:

NATS's unique combination of simplicity and performance makes it ideal for specific architectural patterns.

Optimal use cases:

1. Microservices communication: Lightweight, low-latency inter-service messaging
2. IoT and edge computing: Small footprint, leaf node topology
3. Command and control systems: Real-time commands to distributed agents
4. Service mesh sidecars: Minimal resource consumption per pod
5. Telemetry and metrics: High-frequency, lossy-acceptable data
6. Cloud-native applications: Kubernetes-native, container-friendly

NATS represents a return to messaging fundamentals: simple, fast, and operational efficiency above all. With JetStream, it offers the best of both worlds—ephemeral and persistent messaging in one system.