NATS

2.x (JetStream)

stableCost: mediumTeam: mid level

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.

Consistency & Transactions

Consistency modeleventual

ACID compliantNo

Supports transactionsNo

Scaling

Characteristics

horizontal readhorizontal writefederated

Operational burdenmedium

Typical read latency0.5 ms

Typical write latency0.5 ms

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

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

message brokerevent busservice mesh transportiot ingestion

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

Info

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

Info

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)

low

latency

Sub-millisecond: lowest latency among durable message brokers

low

durability

Strong with JetStream and replication; core NATS is ephemeral

medium

cost

Open source; operational cost lower than Kafka due to simpler infrastructure

low

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

Related Architecture Knowledge

Outbound: this entity affects

ComplementsTechnology

redis

Draft · unverified

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 →

SupportsPattern

competing consumers

Grounded

NATS JetStream consumer groups distribute messages across multiple consumer instances, implementing competing consumers with at-least-once delivery.

Full relationship →

SupportsPattern

publisher subscriber

Grounded

NATS provides sub-millisecond pub/sub messaging with subject hierarchy and wildcard subscriptions, enabling publish-subscribe communication between services.

Full relationship →

Used In Architecture Scenarios

Gaming Backend Platformhigh

Realtime Collaboration

An online multiplayer game backend built around authoritative server game state synchronization. Game rooms run as distributed state machines where the server is the single source of truth for game state: client predictions are reconciled against the server state at every tick. WebSocket connections provide low-latency bidirectional communication for state deltas. Redis stores active game room state (in-flight, with sub-millisecond access), session affinity tokens (routing players to the same server instance as their game room), and matchmaking queues. PostgreSQL is the durable store for player profiles, persistent inventory, leaderboards, and achievement records. Kafka carries post-game event streams for analytics, anti-cheat processing, and achievement evaluation. NATS provides low-latency pub/sub for intra-cluster game state broadcasting when multiple game server instances must coordinate on shared state. Event sourcing records every game action as an immutable event for replay, dispute resolution, and anti-cheat audit.