Beyond streaminglog processing

Kafka is designed for distributed log processing, and at its core (without needing to use Flink or Kafka Streams) that is its sole function. You can do basic publish/subscribe to topics using Kafka, but when it comes to proper low-latency messaging functionality it is not comparable to NATS. At its core, NATS is a dedicated high-speed distributed messaging system designed for low latency, used extensively in real-time environments where latencies have to be measured in microseconds or milliseconds. NATS was designed at Apcera as the core nervous system of a modern PaaS.

Messages

In NATS, messages are fundamentally addressed: every message is published to a subject (a hierarchical name like orders.us.east), and subscribers express interest by subscribing to subjects or subject patterns. The server routes messages based on subject matching. This is true whether or not persistence is involved — core NATS messaging and JetStream both use the same subject-based addressing model.

In Kafka, messages are not addressed. Messages are appended to a specific partition of a specific topic. The only identifier is the offset within that partition. Consumers read from partitions by offset, not by any property of the message itself. To route a message to specific consumers, you either use distinct topics or rely on consumer-side filtering.

"Subjects" vs "Topics"

A NATS subject is a hierarchical dot-separated string (e.g. orders.region.us) that supports wildcard matching: * matches a single token, > matches one or more tokens. A JetStream stream captures messages from one or more subjects (or subject patterns) and stores them durably. Consumers can subscribe to a subset of those subjects within the stream.

A Kafka topic is a durable log divided into partitions. There is no hierarchy, no wildcard subscription at the broker level. Topic filtering or content-based routing requires either multiple topics or a consumer-side filter.

Streaming functionality

JetStream provides streaming on top of NATS subjects. A stream is configured with one or more subject filters (which can include wildcards); any message published to a matching subject is captured and persisted. Streams support configurable retention policies (by count, age, size), deduplication, and sequence-based or time-based replay.

Kafka topics are inherently durable logs with configurable retention. The model is simpler but less flexible: retention is per-topic, not per-message, and there is no native subject-based filtering within a topic.

Qualities of Service

NATS JetStream supports multiple acknowledgment modes: at-most-once (publish without waiting for ack), at-least-once (publish with ack, consumer ack required), and exactly-once semantics through message deduplication at the stream level and double-ack confirmation for consumers. Deduplication is enabled by the Nats-Msg-Id header and a configurable deduplication window.

Kafka's exactly-once semantics require enabling idempotent producers and transactional APIs. The transactional model is powerful but operationally complex: it requires a transaction coordinator, careful producer configuration, and consumer-side read_committed isolation.

Data Store: JetStream persistence enables more than just Streams

JetStream persistence is the foundation for two additional built-in data stores:

Kafka has no native Key/Value or Object Store abstraction. KTables in Kafka Streams provide compacted key-based state, but they are maintained by the Streams application, not the broker. Large object storage typically involves external systems (S3, GCS) with Kafka carrying references or metadata.

Queuing

In NATS, queue semantics are first-class. A queue group is a named set of subscribers; within a group, each message is delivered to exactly one subscriber (load-balanced). This applies to both core NATS messaging and JetStream consumers. No additional process is required.

In Kafka, queue-like semantics are achieved through consumer groups. A topic's partitions are distributed among consumers in a group; each partition is assigned to exactly one consumer. This provides parallelism but ties scaling to partition count — you cannot have more active consumers than partitions. Rebalancing on group membership changes can cause latency spikes.

Cross-cluster behavior

NATS supports multi-region deployments natively through super-clusters (clusters connected via gateways) and leaf nodes (lightweight edge connections). Messages route transparently across cluster boundaries based on subject interest. Stream mirroring and sourcing provide async replication with subject filtering and transformation.

Kafka multi-region deployments typically use MirrorMaker 2 or Confluent's Cluster Linking. MirrorMaker 2 runs as Kafka Connect workers and requires separate configuration and monitoring. Cluster Linking (Confluent Platform) provides tighter integration but is a licensed feature.

Microservices vs CQRS

NATS includes built-in service discovery for request-reply patterns. A service advertises itself by subscribing to a subject; the nats CLI can discover, describe, and benchmark services without external tooling. This makes NATS suitable for both async messaging and synchronous microservice communication.

Kafka is fundamentally asynchronous. Request-reply patterns require application-level correlation IDs and temporary topics. Service discovery requires external mechanisms (DNS, service mesh, Kubernetes services).

Durability

Both systems support configurable replication factors. JetStream streams and KV buckets can be configured with N replicas using Raft consensus. Kafka partitions are replicated across brokers; the producer can require acknowledgment from all in-sync replicas before considering a write committed.

Security models diverge sharply between the two systems — especially around tenancy and the ability to delete individual messages for compliance.

Container orchestration

NATS provides official Helm charts for Kubernetes with full JetStream support. The NATS Kubernetes Operator (NACK) manages streams and consumers declaratively via CRDs.

Kafka has multiple Kubernetes operators: Strimzi (open source) and Confluent for Kubernetes (commercial). Both provide CRD-based management.

Observability and monitoring

NATS exposes built-in HTTP endpoints (/varz, /connz, /jsz, etc.) returning JSON for real-time server state. The system account provides push-based event streams for advisories and stats. NATS Surveyor aggregates metrics across clusters for Prometheus scraping.

Kafka metrics are exposed via JMX. Production deployments typically run JMX exporters alongside each broker, feeding Prometheus or similar systems. The metrics surface is large and requires understanding JMX tooling.

Distributed message tracing

NATS 2.11 introduced built-in distributed message tracing. Setting a Nats-Trace-Dest header causes every server on the message path to publish trace events. The nats trace CLI visualizes the routing tree. A dry-run mode traces without delivering.

Kafka requires OpenTelemetry instrumentation in producers and consumers, propagating trace context through message headers. This traces application-level flow but not internal broker routing.

Debezium Server supports NATS JetStream as a first-class sink. Change events land directly in JetStream streams with full Debezium event structure, no Kafka Connect required.

Kafka remains the primary Debezium target. The Kafka Connect deployment model provides scaling and fault tolerance but requires additional JVM processes.

What NATS adds to CDC

• Subject-based addressing: Route CDC events by table or schema using subject wildcards.
• Key/Value for materialized views: Built-in KV buckets for maintaining entity state.

Other CDC tools

Tools like Sequin provide Postgres-native CDC with built-in NATS sinks, eliminating even the Debezium dependency for PostgreSQL workloads.