NATS
2.x (JetStream)Summary
High-performance cloud-native messaging system supporting at-most-once pub/sub, request-reply, and durable JetStream (at-least-once and exactly-once) streams : designed for low latency and operational simplicity with sub-millisecond delivery at high throughput.
Primary Use Case
Low-latency microservice communication, IoT device telemetry ingestion, event streaming with JetStream, service mesh messaging, and workloads requiring Kafka-like durability with significantly lower operational overhead.
Strengths
Best for
- ·Low-latency microservice request-reply and pub/sub without a separate RPC framework
- ·IoT telemetry ingestion at high fan-in with minimal operational footprint
- ·Event streaming where Kafka's operational complexity is not justified by the workload
- ·Geographically distributed messaging via leaf nodes without full mesh connectivity
Excels when
- ·Sub-millisecond latency matters more than Kafka-scale throughput ceilings
- ·The team wants durable streaming without operating ZooKeeper/KRaft or a JVM-based broker
- ·Both request-reply RPC and pub/sub are needed from the same messaging layer
- ·Geographic distribution via leaf nodes is preferable to a single tightly-coupled cluster
Architectural advantages
- ·Single self-contained binary with no external coordination service dependency
- ·Unified subject space serves pub/sub, request-reply, and JetStream durable streams with one addressing model
- ·Leaf nodes extend the deployment geographically without requiring full cluster mesh connectivity
- ·Sub-millisecond latency profile is competitive with in-memory systems, not just other durable brokers
When to Avoid
Avoid when
- ·The team already depends on Kafka's ecosystem tooling (Kafka Connect, KSQL, Schema Registry)
- ·Core NATS pub/sub is used where delivery cannot tolerate silent message loss to a disconnected subscriber
- ·Consumer lag observability tooling as mature as Kafka's ecosystem is a hard requirement today
Common misuses
- ·Using core NATS (not JetStream) for messages that must survive a disconnected subscriber: core NATS is fire-and-forget and drops undelivered messages silently
- ·Assuming JetStream consumer-group semantics are a drop-in match for Kafka consumer groups without validating ack-policy and redelivery differences
- ·Running high replication factor (R3) JetStream streams without accounting for the added publish latency from quorum acknowledgment
Consistency & Transactions
Scaling
Read scalability
Consumer groups in JetStream allow multiple consumers to share message load. NATS clustering distributes subjects across cluster nodes; clients connect to any cluster member and messages route automatically. Leaf nodes extend the cluster geographically without full mesh connectivity.
Write scalability
JetStream streams receive messages to a persistent log. Multiple producers can publish concurrently. Throughput scales with cluster node count and NVMe I/O. Core NATS (no JetStream) achieves millions of messages/second in memory.
Failure Behavior
Known failure modes
- ·Core NATS is fire-and-forget: if no subscriber is connected, messages are dropped silently
- ·JetStream stream storage exhaustion causes publish failures if limits are not configured
- ·Cluster split-brain during network partition: NATS uses Raft for JetStream leader election
- ·Consumer ack timeout redelivery loops if processing is slower than ack_wait duration
Bottlenecks
- ·Core NATS fire-and-forget semantics: no subscriber connected means silent message loss, not backpressure
- ·JetStream publish latency grows with replication factor due to quorum acknowledgment
- ·Large message payloads (>64KB) reduce throughput; the design center is small, frequent messages
Degradation patterns
- ·Slow consumers in push-mode JetStream cause server-side buffer growth and memory pressure
- ·High replication factor (R3) increases publish latency by requiring quorum acknowledgment
- ·Large message payloads (>64KB) reduce throughput; design for small messages
Recovery considerations
- ·JetStream stream data survives server restart if file_store is configured
- ·Cluster failover: Raft election completes in seconds; brief unavailability during leader re-election
- ·Message replay from JetStream stream provides event sourcing-like recovery for consumers
Architecture Guidance
Common topology roles
Migration notes
- ·NATS JetStream vs Kafka: NATS provides dramatically simpler operations (single binary, no ZooKeeper/KRaft complexity) with a slightly lower throughput ceiling: choose NATS when operational simplicity is the priority
- ·NATS does not support consumer group lag monitoring tooling as mature as Kafka's ecosystem; build custom observability on JetStream consumer pending counts
- ·Migrating from Kafka: NATS subjects map to Kafka topics; JetStream consumers map to Kafka consumer groups; replication factor maps to stream R value
Advisor Guidance
When: scenario needs event streaming with lower operational complexity than Kafka
NATS JetStream provides durable streaming with single-binary deployment; evaluate if Kafka ecosystem tooling (Kafka Connect, KSQL) is required before choosing
When: scenario requires request-reply RPC between microservices
NATS core pub/sub with request/reply semantics provides sub-millisecond service mesh communication without gRPC infrastructure
Comparison Factors
operational complexity
Low: single binary, no external dependencies (no ZooKeeper)
latency
Sub-millisecond: lowest latency among durable message brokers
durability
Strong with JetStream and replication; core NATS is ephemeral
cost
Open source; operational cost lower than Kafka due to simpler infrastructure
Managed Cloud Options
Enables Patterns
Basis
NATS JetStream is a production-grade messaging system with documented benchmarks and case studies; the core NATS server and JetStream implementation are thoroughly documented in official NATS documentation
Sources & Claims
Core NATS (without JetStream) provides at-most-once, fire-and-forget delivery: if no subscriber is connected to a subject when a message is published, that message is dropped silently with no persistence or redelivery
pendingofficial documentation · NATS documentation, Core NATS concepts and JetStream comparison
messaging-knowledge-completion batch, added alongside SQS/Pub-Sub/Pulsar profiles
JetStream stream replication uses Raft consensus for leader election; a higher replication factor increases publish latency because acknowledgment requires quorum agreement across replicas
pendingofficial documentation · NATS documentation, JetStream Clustering and Replication guide
messaging-knowledge-completion batch
Related Architecture Knowledge
Outbound: this entity affects
NATS provides durable messaging with JetStream; Redis provides in-memory caching and pub/sub. NATS is used for reliable event delivery; Redis is used for low-latency session state and rate limiting, with both used in the same application stack.
Full relationship →NATS JetStream consumer groups distribute messages across multiple consumer instances, implementing competing consumers with at-least-once delivery.
Full relationship →NATS provides sub-millisecond pub/sub messaging with subject hierarchy and wildcard subscriptions, enabling publish-subscribe communication between services.
Full relationship →