Technology deep-dive

NATS JetStream: the lightweight Kafka alternative, and why durability disqualifies it for security data.

NATS JetStream is impressive at one thing: low-latency, low-footprint streaming with a single binary and sub-second startup. For edge collection, that may be exactly the right shape. For the core of a security data pipeline, the December 2025 Jepsen analysis of v2.12.1 quantified durability failures that I think disqualify it: 14.1% message loss on coordinated power failure, 49.6% with single-bit corruption on one of five nodes, up to 78% of acknowledged writes lost on individual nodes under split-brain conditions, and a default fsync interval that violates the basic Raft invariant of syncing before acknowledgment. A v2.12.5 consumer-loss regression surfaced in a March 2026 GitHub discussion added a new data loss path that Synadia's own tests missed.

Reading time: about 14 minutes. Evidence tiers mixed: the Jepsen analysis is Tier A (independent expert testing, transparent methodology), enterprise adoption claims are Tier B (vendor announcement with named customers), and the security-specific extrapolations are Tier C-D (no documented security production case studies exist). The Jepsen findings are specific to v2.12.1; Synadia's response blog names v2.12.3 fixes around peer-removal and cluster-membership plus contributions to the Jepsen test library, but the core filestore-corruption recovery gap is still open as of May 2026, and no independent post-v2.12.3 Jepsen re-test has been published. Notably, Synadia chose to document the 2-minute deferred-fsync default as a risk in that response rather than change the default.

NATS is a CNCF incubating project written in Go, with more than 40,000 GitHub stars and real enterprise adoption. JetStream is the persistence layer built on top of NATS's core pub-sub: it adds durability (in principle), message replay, and consumer state to what was previously a fire-and-forget messaging system. Synadia is the commercial entity behind NATS, with named customers including Walmart, Rivian, FinecoBank, Replit, and PowerFlex, and a Series B announcement in March 2025 claiming 200% YoY customer growth.

The operational story is attractive. Where Kafka asks for multiple JVMs plus ZooKeeper or KRaft, NATS is a single binary (nats-server). Where Kafka cold-starts in 20-30 seconds, NATS starts in sub-second. Where Kafka needs 4-16 GB minimum memory, NATS typically runs in 1-4 GB. There are no external dependencies and no GC tuning to do, because Go's runtime handles it. Installing it on a dev machine is two commands:

# Install
brew install nats-server  # or download binary

# Start with JetStream enabled
nats-server -js

That's it: one command, one process, and streaming is enabled. The Go API surface for a publisher/consumer is similarly compact:

// Connect and create JetStream context
nc, _ := nats.Connect(nats.DefaultURL)
js, _ := nc.JetStream()

// Publish security event
js.Publish("security.events.auth", eventData)

// Subscribe with durable consumer
js.Subscribe("security.events.auth", func(msg *nats.Msg) {
    processSecurityEvent(msg.Data)
    msg.Ack()
}, nats.Durable("alert-processor"), nats.ManualAck())

I want to credit this honestly: the developer experience is excellent, and the operational footprint at the edge is a clear improvement over Kafka. If the only thing that mattered was time-to-first-message and resource overhead, NATS JetStream wins this comparison without a serious argument.

Jepsen, the consultancy run by Kyle Kingsbury, is the industry's gold standard for distributed-systems reliability testing. Jepsen has tested Kafka (multiple times, with documented fix cycles), CockroachDB, MongoDB, Redis, etcd, and dozens of others. The methodology is transparent, the test harness is open source, and the findings are independently reproducible. When Jepsen publishes a Tier A analysis, the results carry more weight than vendor benchmarks or community blog posts, and the December 2025 analysis of NATS v2.12.1 is, in my reading, disqualifying for security data on the core path.

"NATS JetStream promises that once a publish call has been acknowledged, it is 'successfully persisted'. This is not exactly true."

That quote from the Jepsen analysis is the headline, and the quantified findings underneath it are stark: 14.1% message loss (131,418 of 930,005 acknowledged messages) in a LazyFS-coordinated power-failure scenario, 49.6% total message loss (679,153 of 1,367,069) from a single-bit error in a .blk file on one of five nodes, individual nodes losing up to 78% of acknowledged writes under split-brain conditions, and 30-second write loss windows in typical failure scenarios. These are not edge cases dreamed up by an adversarial researcher, because power failures happen, disk corruption happens, and network partitions happen. In a security telemetry pipeline, a 14% message loss rate means roughly 14% of an adversary's activity goes silently undetected, and the 78% split-brain figure is the number that ought to be most alarming, because it means a single partition can leave a node blind to its own recent history.

The Jepsen report attributes the losses to four specific issues, each with a GitHub tracking ticket:

• Lazy fsync (#7564). The default sync_interval is 2 minutes. That means when NATS acknowledges a write to your application, the data may still be sitting in volatile OS page cache for up to 2 minutes. This violates the foundational Raft invariant that you sync to disk before acknowledging. Kafka's defaults are safer here. Synadia's response to the Jepsen analysis documented this default as a risk rather than flipping it; the configuration that produced the 14.1% loss number is still what a fresh install ships with.
• .blk file corruption (#7549). Minority node corruption cascades to cause majority data loss. A single-bit error in a .blk file on one of five nodes triggered 49.6% total message loss in Jepsen's testing.
• Snapshot corruption triggering stream deletion (#7556). A corrupted snapshot can trigger complete stream deletion rather than a graceful recovery path. This is the kind of failure mode where the only acceptable behavior is "fail loudly," and the observed behavior is "silently destroy the data."
• Split-brain from a single OS crash (#7567). A single OS crash plus pause produces divergent replicas. A clustered system should withstand more than one machine misbehaving without losing consensus.

The lazy-fsync issue is the one I keep returning to. Most consumers of a streaming system assume that "acknowledged" means "persisted to durable storage." That's the contract Kafka offers (with safe defaults), the contract Raft systems generally offer, and the contract the rest of the security data stack assumes. A 2-minute default fsync window means that contract is not actually being honored, and the language in the documentation has been generous about that. The fact that this was the default, not an opt-in performance mode, is what moves this from "tuning concern" to "architectural objection."

Kafka is not perfect. The Kafka deep-dive I wrote separately catalogs its own operational complexity, resource overhead, and learning curve, and I would not pretend any of those are zero costs. But on the single dimension that matters most for security data ("did we lose the event?") Kafka has a decade of independent verification, multiple Jepsen analyses (2013, 2018, 2020) with documented fix cycles and subsequent re-verification, peer-reviewed research, and extensive multi-organization production deployment evidence at LinkedIn (1 trillion+ messages/day), Netflix, Uber, and Cloudflare.

NATS JetStream's durability evidence base sits at a different category. A single Jepsen analysis (v2.12.1) with findings that include 14.1% loss on coordinated power failure, 49.6% loss from a single-bit error on one of five nodes, and up to 78% acknowledged-write loss on individual nodes under split-brain. A "NATS-optimized" Raft implementation with no formal proof and no TLA+ specification published. A 2-minute default fsync interval that violates sync-before-acknowledgment and that Synadia has chosen to document rather than change. No independent post-v2.12.3 Jepsen re-test. A v2.12.5 consumer-loss regression (Discussion #7967) on a version meant to incorporate Jepsen-prompted fixes. Single-organization production validation (Synadia Cloud) without the multi-org, peer-published track record Kafka has accumulated.

These are not symmetric arguments. A security architect evaluating a streaming layer for the core path is making a multi-year commitment to a system whose failure modes will determine whether incident response and compliance reporting are reliable. The asymmetry of consequences (a missed event versus an unnecessary engineering investment) argues for the system with the longer independent verification track record, even at the cost of higher operational overhead at deployment time.

If you have a use case where NATS JetStream's operational simplicity earns its place (I describe one candidate below) there is a configuration discipline worth following. The minimum config changes I would not deploy without:

# nats-server.conf - REQUIRED for durability
jetstream: enabled
jetstream:
  sync_interval: always  # Default is 2 minutes (dangerous)
  max_memory: 4GB
  store_dir: /var/nats/jetstream

Beyond sync_interval: always, the additional disciplines I'd insist on for any deployment carrying security-relevant data:

• R=5 replication rather than the default R=3. The minority-node corruption finding (#7549) cascaded in the default replication factor. Higher replication doesn't fix the underlying bug but reduces the probability of the cascade triggering.
• Application-level durability checks. Checksums on every message, sequence validation on every consumer, dead-letter queues for messages that fail validation. Treat the transport as potentially lossy and prove durability at the application layer.
• Treat NATS as transport, not as store. Forward to Kafka or directly into Iceberg for durable retention as quickly as possible. Don't rely on NATS for the system of record.

I want to flag honestly: even with sync_interval: always and R=5, the .blk corruption and snapshot deletion issues (#7549, #7556) are not configuration problems. They are implementation bugs at the time the Jepsen analysis was published. Whether they remain unfixed in current releases is the kind of question that ought to be answered by independent re-verification before any architect bets on it.

The pattern that makes the most architectural sense, if you want NATS in the picture at all, is to use it where its strengths line up (at the edge) and to use Kafka where durability is the binding constraint (at the core).

The edge layer collects from thousands of agents and sensors, pre-aggregates and filters at the collection point, and offers sub-millisecond latency for any alerting that needs to fire at the edge. The core layer provides durable storage for compliance, mature Iceberg connectors, proven petabyte-scale behavior, and the broader Kafka ecosystem (Connect, Schema Registry, ksqlDB) that security pipelines tend to grow into.

This is an informed hypothesis rather than a documented production pattern in security contexts; I have not yet seen a named security operation publicly describe deploying NATS-edge plus Kafka-core in production. It's Tier D evidence at best, and it's the kind of architecture I'd want to validate on a lab benchmark with security-shaped workloads before committing to it for a customer.

NATS JetStream may be appropriate if

• You are building an edge-only collection layer, not a core pipeline.
• Loss of individual messages is tolerable for the use case, with durability proven at a downstream layer.
• You configure sync_interval: always and R=5 replication.
• You forward all data to a durable store (Kafka, Iceberg) immediately rather than relying on NATS retention.
• Your per-stream volume is under roughly 100 GB/day.
• Sub-millisecond latency genuinely justifies accepting the durability risk profile.
• You do not have PCI-DSS, SOC 2, or NIST audit obligations on the data path NATS carries.

Use Kafka if

• Any data loss compromises detection coverage, compliance reporting, or financial integrity.
• You sustain more than 1 TB/day through a single pipeline.
• You need the Kafka Connect ecosystem (100+ connectors with security-relevant integrations).
• You need exactly-once semantics with transactions.
• You're building lakehouse integration, where Kafka-to-Iceberg connectors are the mature path.
• Your team already operates Kafka and the operational learning curve is sunk cost.
• You need independently verified durability, with multi-Jepsen-cycle history and multi-organization production validation.

For most security operations evaluating a streaming layer today, the answer is Kafka at the core and a careful evaluation of NATS or Redpanda at the edge if specific deployment constraints make a single-binary, low-footprint collector necessary. I would not currently recommend NATS JetStream as a Kafka replacement for the core security pipeline.