DEV Community: Dave Maman

Beyond Kafka and Redis, Part 2: An AI Chat Backend on NATS 2.15

Dave Maman — Wed, 07 Oct 2026 02:46:33 +0000

In part 1 I walked through the NATS building blocks one at a time: subjects, request-reply, JetStream streams, the Key-Value store, and the Object Store. That post answered "what can NATS replace?" This one builds a real backend with it.

The system is the backend for an AI chat product. It has a GPU work queue, token streaming to the browser, conversation history, per-tenant usage metering, run timeouts, and worker ownership of conversations. In a typical stack that's Kafka or SQS for the queue, Redis for counters and locks, a cron service for timeouts, Postgres for history, and a WebSocket gateway for streaming.

NATS has shipped four minor releases since part 1: 2.11, 2.12, 2.14, and 2.15 (2.13 was skipped). Several of the new features close gaps that used to push you toward one of those other systems. Each section below takes one problem, shows the feature that handles it, and shows code I ran against nats-server 2.15.0 with nats.js 3.4.0. The full scripts are in nats-backbone-examples.

What's new since part 1

Release	Feature	What it handles
2.11	Per-message TTL (`Nats-TTL`)	Expiring one message without a stream-wide `MaxAge`
2.11	Per-key TTL in KV	Locks and leases that expire on their own
2.11	Priority groups: `overflow`, `pinned_client`	Sending work to preferred workers first
2.11	Consumer pause	Stopping delivery during a deploy without deleting the consumer
2.12	Atomic batch publish	Writing several messages all-or-nothing
2.12	Distributed counters	`INCR` across regions without double counting
2.12	Delayed messages (`@at`)	Timeouts and reminders without a cron service
2.12	`prioritized` priority policy	Failover that moves work sooner than `overflow`
2.14	Recurring schedules (`@every`, cron) and subject sampling	Periodic jobs and downsampling
2.14	Atomic schedule cancel	Clearing a timeout in the same publish that finishes the work
2.14	Fast-ingest batch publish	High-throughput ingest with server-side flow control
2.14	Consumer reset	Reprocessing from a sequence without recreating the consumer
2.14	Mirroring WorkQueue and Interest streams	Disaster recovery for queues
2.15	Stream backup v2, evacuate, desired-state metalayer	Safer node replacement and backups
2.15	Default limit of 1,000 consumers per stream	Protection from runaway consumer creation

A note on part 1

I've fixed three code errors in part 1. The KV ttl option in nats.js is in milliseconds (part 1 passed nanoseconds, which set it to about 114 years). KV keys can't contain :. Optimistic locking uses kv.update(), not a previousRevision option. If you copied the KV examples, check them again.

The subject layout

Every piece of state in this backend lives on a subject. The layout is the design, so it comes first:

inference.jobs.<tenant>             INFERENCE      work queue for GPU workers
chat.<conv>.run.<run>.chunk         CHAT           streamed tokens, 1 hour TTL
chat.<conv>.run.<run>.done          CHAT           end of a reply
chat.<conv>.run.<run>.deadline      CHAT           schedule that fires the timeout
chat.<conv>.run.<run>.timeout       CHAT           written by the schedule
history.<conv>                      HISTORY        committed conversation turns
usage.<region>.<tenant>.tokens      USAGE_<REGION> per-region counters
usage.all.<tenant>.tokens           USAGE_GLOBAL   aggregated counters
$KV.leases.<conv>                   KV "leases"    which worker owns a conversation

A few rules shaped it. Each run gets its own subjects, so a client can replay exactly one reply. The tenant or conversation ID sits in a fixed token position, so permissions and filters can match on it. Things with different lifetimes live in different streams: tokens are short-lived, history is permanent, and counters have their own stream type.

1. A GPU queue with paid overflow

You run inference on your own GPUs. When they fall behind, you want to rent burst capacity, but only while there's a real backlog. With Kafka or SQS you'd build this yourself: watch the queue depth, scale a second worker pool up and down, and hope the metrics lag doesn't cost you.

Priority groups (2.11) put this rule in the consumer. With the overflow policy, each pull can include a min_pending threshold. The server answers that pull only when the consumer has at least that many messages waiting.

await jsm.streams.add({
  name: "INFERENCE",
  subjects: ["inference.jobs.>"],
  retention: "workqueue",
});

await jsm.consumers.add("INFERENCE", {
  durable_name: "gpu-workers",
  ack_policy: AckPolicy.Explicit,
  priority_policy: "overflow",
  priority_groups: ["gpu"],
});

const consumer = await js.consumers.get("INFERENCE", "gpu-workers");

// Your own GPUs: always pull.
const onPrem = await consumer.fetch({ max_messages: 10, expires: 2000, group: "gpu" });

// Rented burst capacity: only gets work while 25 or more jobs are waiting.
const burst = await consumer.fetch({
  max_messages: 10,
  expires: 2000,
  group: "gpu",
  min_pending: 25,
});

With 60 jobs queued and both pools pulling 10 at a time:

round 0: on-prem=10 burst=10 pending=40
round 1: on-prem=10 burst=8 pending=22
round 2: on-prem=10 burst=0 pending=12
round 3: on-prem=10 burst=0 pending=2
round 4: on-prem=2 burst=0 pending=0

The burst pool stopped mid-round once the backlog dropped under 25. The on-prem pool finished the rest.

Two other policies cover related cases. pinned_client sends everything to one client until it stops pulling, which suits a single active processor with a hot standby. prioritized (2.12) lets each pull carry a priority number, and the server serves lower numbers first.

The catch: once a consumer has a priority policy, every pull must name the group. A pull without group is rejected with Priority Group missing.

2. Streaming replies that survive a reconnect

Token streaming is where most chat backends get fragile. The usual setup sends tokens over a WebSocket or SSE connection from the server that runs the model. If the browser drops for two seconds, or the user reloads, those tokens are gone. Teams patch this with Redis Streams or a buffer table, plus resume logic.

In this design the responder publishes each token chunk into the CHAT stream. The browser reads with a consumer, keeps the stream sequence of the last chunk it rendered, and resumes after that sequence when it reconnects. The stream is the buffer.

Chunks are only useful for a short time, but CHAT also holds things you may want longer. Per-message TTL (2.11) handles that: each chunk carries its own lifetime, and the rest of the stream keeps its normal limits.

await jsm.streams.add({
  name: "CHAT",
  subjects: ["chat.>"],
  allow_msg_ttl: true,
  allow_msg_schedules: true,
});

// Responder: one message per token, each kept for an hour.
for (const token of tokens) {
  await js.publish(`${base}.chunk`, JSON.stringify({ token }), { ttl: "1h" });
}
await js.publish(`${base}.done`, JSON.stringify({ chunks: tokens.length }));

The reader resumes from a cursor:

async function readRun(base: string, afterSeq = 0) {
  const c = await js.consumers.get("CHAT", {
    filter_subjects: [`${base}.chunk`, `${base}.done`],
    ...(afterSeq
      ? { deliver_policy: DeliverPolicy.StartSequence, opt_start_seq: afterSeq + 1 }
      : {}),
  });
  // ...consume, record m.seq after each rendered chunk, stop at ".done"
}

Reading four tokens, dropping, and resuming from the saved cursor:

before disconnect: NATS keeps the reply (cursor 5)
after reconnect:   until the client catches up

The cursor is a stream sequence, not a token index. Other subjects in CHAT take sequence numbers too, which is why the fourth token sits at sequence 5.

The catch: a TTL deletes the message whether or not anyone read it. Set it longer than the longest time a client can be away and still expect to resume. Also, allow_msg_ttl can't be turned off once it's on.

In a browser, nats.js connects over WebSockets and the same code works. The extra work is around it: a cursor that survives a page reload (IndexedDB is enough), replay that finishes before you render live tokens, and one connection shared across components instead of one per component.

I've been building a side project for that part, NATSail. It's a TypeScript runtime with React, RxJS, and Effect adapters, and its repo has runnable chat apps on these patterns. The AI chat example streams Vercel AI SDK and TanStack AI replies over JetStream and has buttons that drop the connection or reload the page mid-reply. You don't need it for anything in this post.

3. Run deadlines without a cron service

A model call can stall. Without a deadline, the user watches a spinner forever. The usual fix is a timer in the responder process (lost when it crashes) or a delayed job in a separate queue (another system).

Message schedules (2.12, extended in 2.14) let the stream fire the timer. When a run starts, the responder publishes a schedule message with an @at time. If the run isn't finished by then, the server writes a message to the target subject. When the run finishes, the .done publish cancels the schedule in the same operation.

// When the run starts
await js.publish(`${base}.deadline`, JSON.stringify({ reason: "deadline" }), {
  schedule: {
    specification: new Date(Date.now() + 30_000),
    target: `${base}.timeout`,
  },
});

// When the run finishes: store ".done" and remove the schedule together
await js.publish(`${base}.done`, JSON.stringify({ chunks: n }), {
  cancelSchedule: { scheduleSubject: `${base}.deadline` },
});

I ran two runs with short deadlines. run-1 finished. run-2 sent three tokens and stopped:

timeouts fired: [ 'chat.conv-42.run.run-2.timeout' ]
timeout body: {"reason":"deadline"}

The timeout lands in the same stream as the chunks. A browser that's already reading the run sees it in order and can show "the model stopped responding" instead of a spinner. A cleanup worker can subscribe to chat.*.run.*.timeout and mark the run failed.

The schedule survives a responder crash because it lives in the stream, replicated like any other message. That's the property the in-process timer was missing.

Schedules do more than one-shot timers. @every 5m and 6-field cron expressions (with a time zone) arrived in 2.14. A schedule with source set publishes the latest message from another subject on each tick, which gives you downsampling: copy the latest value of a busy sensor subject into an hourly subject, for example.

The catch: each schedule needs its own subject, and the target must be a different subject in the same stream. A stream with schedules can't use discard: new or be a mirror.

4. Writing a conversation turn all at once

One turn in an agent conversation is several records: the user message, each tool call, each tool result, and the assistant's answer. If the writer crashes partway, history holds half a turn, and the next model call gets a broken context. In Postgres you'd use a transaction. With plain JetStream you'd write one large message per turn, or accept the risk.

Atomic batch publish (2.12) stores a group of messages as a unit. Nothing is visible until the commit, and a failed batch stores nothing.

The more interesting part is concurrency. Two agents (or two retries of one agent) can both read the conversation at sequence 4 and both try to write the next turn. Put a lastSubjectSequence expectation on the first message of the batch, and only one turn commits.

await jsm.streams.add({
  name: "HISTORY",
  subjects: ["history.>"],
  allow_atomic: true,
});

async function appendTurn(conv: string, expectedLastSeq: number, entries: Entry[]) {
  const subject = `history.${conv}`;
  const [first, ...rest] = entries;
  const last = rest.pop()!;

  const batch = await js.startBatch(subject, JSON.stringify(first), {
    expect: { lastSubjectSequence: expectedLastSeq },
  });
  for (const e of rest) batch.add(subject, JSON.stringify(e));
  return batch.commit(subject, JSON.stringify(last));
}

Writing the first turn, then two competing second turns:

turn 1 committed: batch of 4, last seq 4
committed at 6
rejected: batch didn't contain number of published messages
messages stored: 6

Four messages from turn 1, two from the winning turn 2, and nothing from the loser. The losing agent re-reads the conversation and decides what to do.

The catch: a batch is capped at 1,000 messages by default, and the server drops a batch that goes 10 seconds without a new message. The commit's ack is the only proof the batch landed. Atomic batches also don't work on a stream with persist_mode: async.

If what you need is throughput rather than all-or-nothing, look at fast-ingest batch publish (2.14, allow_batched). The server paces the publisher with flow control and acks in groups. You choose whether a gap aborts the batch or is reported and skipped.

5. Token usage per tenant, across regions

Usage metering is usually a Redis INCRBY per tenant, then a job that copies totals into the billing database. Run in two regions and you either pick one region's Redis as the source of truth (cross-region latency on every request) or sum two Redis instances yourself.

Distributed counters (2.12) turn a stream into a counter. You publish an increment in the Nats-Incr header, and the server stores the running total for that subject. Counter streams can source from other counter streams, and the server tracks what it has already counted from each source, so the global total doesn't double count.

for (const region of ["us", "eu"]) {
  await jsm.streams.add({
    name: `USAGE_${region.toUpperCase()}`,
    subjects: [`usage.${region}.>`],
    allow_msg_counter: true,
    allow_direct: true,
  });
}

await jsm.streams.add({
  name: "USAGE_GLOBAL",
  subjects: [],
  allow_msg_counter: true,
  allow_direct: true,
  sources: [
    { name: "USAGE_US", subject_transforms: [{ src: "usage.us.>", dest: "usage.all.>" }] },
    { name: "USAGE_EU", subject_transforms: [{ src: "usage.eu.>", dest: "usage.all.>" }] },
  ],
});

async function addTokens(region: string, tenant: string, n: number) {
  const h = headers();
  h.set("Nats-Incr", n >= 0 ? `+${n}` : `${n}`);
  await js.publish(`usage.${region}.${tenant}.tokens`, "", { headers: h });
}

async function read(stream: string, subject: string) {
  const m = await jsm.direct.getMessage(stream, { last_by_subj: subject });
  return m ? m.json<{ val: string }>().val : "0";
}

After 1,200 and 800 tokens in the US, and 450 tokens minus a 50-token refund in the EU:

us:     2000
eu:     400
global: 2400

In production each regional stream lives in its own cluster, and USAGE_GLOBAL sources across them. Each region writes locally, and the global view converges.

The value is a string ({"val":"2400"}) so it can go past JavaScript's 2^53 limit. The examples set the header by hand to show the protocol. The @synadiaorbit/counters package wraps it.

The catch: counter streams must use limits retention, can't be turned off after creation, and can't be combined with per-message TTL, schedules, mirrors, or discard: new. Keep counters in their own streams.

6. One worker per conversation

Only one agent worker should act on a conversation at a time. That's a lease: take it if it's free, keep renewing while you work, and let it expire if you crash. The standard tool is Redis SET NX PX plus a Lua script for safe renewal.

Per-key TTL (2.11) does this in the KV store. kv.create() fails if the key exists, and its third argument sets a TTL on that key only. The bucket's markerTTL makes the server leave a marker when a key expires, so watchers learn about it.

const kv = await new Kvm(nc).create("leases", { markerTTL: 60_000 });

async function acquire(conv: string, worker: string) {
  try {
    return await kv.create(conv, worker, "3s"); // returns the revision
  } catch {
    return 0; // someone else holds it
  }
}

// The KV client has no "update with TTL", so publish to the bucket's subject.
// The expectation makes renewal fail if someone else took the lease.
async function renew(conv: string, worker: string, revision: number) {
  const ack = await js.publish(`$KV.leases.${conv}`, worker, {
    ttl: "3s",
    expect: { lastSubjectSequence: revision },
  });
  return ack.seq;
}

The renewal shows something useful about KV: a bucket is a stream named KV_<bucket>, and each key is the subject $KV.<bucket>.<key>. When the KV client doesn't expose an option, the stream publish API usually does.

Worker A takes the lease, renews once, and then crashes:

worker-a acquired at rev 1
  watch: conv-42 PUT worker-a
worker-b acquire: refused
worker-a renewed, rev 2
  watch: conv-42 PUT worker-a
worker-a stops renewing (crash)...
  watch: conv-42 PURGE
worker-b acquire: 4

The PURGE entry is the expiry marker. A supervisor watching the bucket can see a lease expire and reassign the conversation right away instead of waiting for someone to poll.

The catch: a lease is a liveness hint, not a fence. A worker that pauses for longer than the TTL can wake up and keep working after someone else took over. Check the lease revision before side effects that matter, the same as with any lease.

Operating it

The newer releases also made day-two operations easier. Here's what I'd use in this backend.

Pause a consumer during a deploy (2.11). Messages keep landing in the stream, and delivery resumes on its own at the deadline or when you call resume.

await jsm.consumers.pause("EMBED", "indexer", new Date(Date.now() + 15 * 60_000));
await jsm.consumers.resume("EMBED", "indexer");

Reprocess after a bug fix (2.14). Before, you deleted and recreated the consumer at a start sequence. Now you reset it in place, and it keeps its name and config:

const r = await jsm.consumers.reset("EMBED", "indexer", 4);
console.log(r.num_pending); // 7: sequences 4 through 10 are pending again

Back up a stream in a readable format (2.15). Backup v2 stores messages in a format the CLI can parse and edit, rather than the on-disk format. It also works for memory-backed streams, which the old format didn't support.

Drain a node before you replace it (2.15). The evacuate endpoints move every stream and consumer off a server, keeping their replica counts. Scaling and moving streams now runs on a desired-state loop, so an interrupted move resumes instead of getting stuck. Upgrade from 2.14.7 or later before going to 2.15.

Watch the new consumer limit (2.15). Streams now default to a maximum of 1,000 consumers. That includes ephemeral consumers and KV watchers. If every browser tab opens its own consumer on CHAT, you'll reach it. Raise max_consumers on that stream on purpose, or share one consumer per page instead of one per component.

Plan for the 2.16 ack subject change. Starting in 2.16, ack and flow-control subjects include the JetStream domain and an account hash. If your permissions or account exports list $JS.ACK.<stream>.> (or anything narrower), update them first. A catch-all $JS.ACK.> is unaffected. On 2.14 or 2.15 you can test the new format now with feature_flags { js_ack_fc_v2: true }.

Where NATS still isn't the answer

Part 1 said NATS won't replace Postgres. That's still true, and building this backend made the line clearer.

Queries. HISTORY replays one conversation in order. It can't answer "all conversations where the agent called the weather tool last week." Project the stream into a database for that.
Large files. The Object Store is good for model configs, adapters, and attachments in the megabytes to low gigabytes. For a data lake, use object storage built for it.
Client support for the newest features. nats.js 3.4 covers schedules and atomic batches in the main package, but fast ingest comes from the Synadia Orbit @synadiaorbit/fastingest package. Other languages reach several of these features through Orbit too, and fast-ingest support is still landing in Python, Java, and .NET. Check your language before you design around a feature.

The rest of the backend runs on one NATS cluster. Every stream above can be replicated with num_replicas: 3, and each feature uses the same stream mechanics, so the same backups, mirrors, and monitoring cover all of it.

Try it

brew install nats-server nats-io/nats-tools/nats
nats-server -js

You need server 2.14 or later for every example (2.15 to match the output above). Then run the examples from this post with Node 22 or later:

git clone https://github.com/thedonmon/nats-backbone-examples
cd nats-backbone-examples/part-2
npm install
npx tsx 01-overflow.ts

Each script creates the streams it needs and deletes them on exit. Set NATS_URL if your server isn't on 127.0.0.1:4222.

Resources

NATS 2.15 upgrade guide, with the 2.14 and 2.12 guides
ADR-42: Priority groups
ADR-49: Distributed counters
ADR-50: Batch publishing
ADR-51: Message schedules
nats.js
Examples for this post
NATSail

If you're running any of these patterns in production, or you found a case where they break down, I'd like to hear about it.

Beyond Kafka and Redis: A Practical Guide to NATS as Your Unified Cloud-Native Backbone

Dave Maman — Mon, 02 Feb 2026 08:20:15 +0000

Updated October 2026: fixed three code errors (KV TTL units, KV key names, and the optimistic-locking option) and tightened the wording. Part 2 builds an AI chat backend with the features NATS added in 2.11 through 2.15.

A common platform setup looks like this. Kafka handles event streaming, with its KRaft controllers and partition planning. Redis Sentinel handles sessions and rate limits. S3 or MinIO stores model weights and config files. Each system has its own runbook, its own dashboards, and its own ways to fail.

When you get paged at 3 AM, you're debugging that infrastructure as well as your application.

NATS can cover most of that stack with one server binary. It's been running large distributed systems for over a decade. With JetStream, the Key-Value store, and the Object Store now mature, it's a full messaging platform as well as a fast pub/sub system.

This post walks through each piece with working code.

What NATS replaces

Need	Usual tool	NATS feature
Pub/sub messaging	Redis Pub/Sub, Kafka topics	Core NATS subjects
Persistent streaming	Kafka, Pulsar, Kinesis	JetStream streams
Key-value storage	Redis, etcd, Consul KV	KV store
Object and blob storage	S3, MinIO	Object Store
Request-reply between services	HTTP, gRPC	Built-in request-reply
Service discovery	Consul, Eureka, Kubernetes DNS	Services framework

The operational difference is large. A production Kafka deployment usually means:

A KRaft controller quorum (Kafka 4.0 removed ZooKeeper; older clusters still run it)
Broker nodes with partition and replication planning
A schema registry for Avro or Protobuf
Kafka Connect for data pipelines
JMX exporters for monitoring

A NATS server with persistence is one command:

nats-server -js

There are no external dependencies. The -js flag turns on JetStream.

Core NATS

Core NATS moves messages between publishers and subscribers on named subjects, like events.user.signup. Nothing is stored at this layer. If no subscriber is listening when a message arrives, the message is dropped. In exchange, latency is typically under a millisecond.

Start the server

# Run the binary
nats-server

# Or with Docker
docker run -p 4222:4222 nats:latest

# Turn on JetStream for persistence
nats-server -js

Publish and subscribe

import { connect } from "@nats-io/transport-node";

const nc = await connect({ servers: "localhost:4222" });

// Subscriber (usually another process)
const sub = nc.subscribe("events.user.*");
(async () => {
  for await (const msg of sub) {
    console.log(`Received on ${msg.subject}:`, msg.string());
  }
})();

// Publisher
nc.publish("events.user.signup", JSON.stringify({
  userId: "user-123",
  email: "dev@example.com",
  timestamp: Date.now(),
}));

events.user.* matches one token in that position, so the subscriber gets events.user.signup, events.user.login, and so on. > matches one or more tokens at the end of a subject.

With Kafka, the same flow needs a topic created with partitions and a replication factor, producer serializers, and a consumer group that handles partition assignment and rebalancing. With NATS you publish to a subject and subscribe to it.

Request-reply

NATS has request-reply built in, so internal services can call each other without HTTP or gRPC:

// Service: answer requests
const svc = nc.subscribe("api.users.get");
(async () => {
  for await (const msg of svc) {
    const { userId } = msg.json<{ userId: string }>();
    const user = await db.findUser(userId);
    msg.respond(JSON.stringify(user));
  }
})();

// Client: send a request and wait for the reply
const response = await nc.request(
  "api.users.get",
  JSON.stringify({ userId: "user-123" }),
  { timeout: 5000 },
);
console.log("User:", response.json());

If several instances subscribe with the same queue group (nc.subscribe("api.users.get", { queue: "users" })), NATS sends each request to one of them. That's load balancing without a load balancer.

For AI workloads: request-reply fits synchronous inference. The application sends a prompt to inference.chat.query, one model server in the queue group takes it, and the reply comes back on the same connection. Add model servers and they share the load.

JetStream: persistent streams

JetStream is the persistence layer. A stream stores every message published to its subjects, and consumers read from it, with acknowledgment and replay. It runs inside the same server, so there's no second cluster to manage.

Create a stream

With the CLI:

nats stream add ORDERS \
  --subjects "orders.*" \
  --retention limits \
  --max-msgs 1000000 \
  --max-bytes 1GB \
  --max-age 7d \
  --defaults

--defaults accepts the default for every setting you didn't pass. Without it, the CLI prompts for each one.

Or in code:

import { connect } from "@nats-io/transport-node";
import { AckPolicy, DeliverPolicy, jetstream, jetstreamManager } from "@nats-io/jetstream";

const nc = await connect({ servers: "localhost:4222" });
const jsm = await jetstreamManager(nc);

await jsm.streams.add({
  name: "ORDERS",
  subjects: ["orders.*"],
  retention: "limits",
  max_msgs: 1_000_000,
  max_bytes: 1024 * 1024 * 1024, // 1 GB
  max_age: 7 * 24 * 60 * 60 * 1_000_000_000, // 7 days, in nanoseconds
});

Stream durations like max_age are in nanoseconds. Remember that when you get to the KV section, because nats.js KV options use milliseconds.

Publish to a stream

const js = jetstream(nc);

const ack = await js.publish("orders.created", JSON.stringify({
  orderId: "ORD-12345",
  customerId: "CUST-789",
  items: [{ sku: "WIDGET-01", quantity: 2 }],
  total: 49.99,
}));
console.log(`Stored in ${ack.stream} at sequence ${ack.seq}`);

// Deduplicate retries with a message ID
await js.publish("orders.created", JSON.stringify({ orderId: "ORD-12346" }), {
  msgID: "ORD-12346",
});

A JetStream publish waits for the server to confirm it stored the message. With msgID, a retry of the same publish inside the stream's duplicate window (two minutes by default) is dropped instead of stored twice. Delivery to consumers is at-least-once. For exactly-once processing, combine msgID on publish with ackAck() on the consumer, which waits for the server to confirm the ack.

Consume with a durable consumer

await jsm.consumers.add("ORDERS", {
  durable_name: "order-processor",
  ack_policy: AckPolicy.Explicit,
  deliver_policy: DeliverPolicy.All, // start from the first message
  filter_subject: "orders.created",
  max_ack_pending: 100,
});

const consumer = await js.consumers.get("ORDERS", "order-processor");
const messages = await consumer.consume();

for await (const msg of messages) {
  const order = msg.json<{ orderId: string }>();
  console.log(`Processing order ${order.orderId}`);
  await processOrder(order);
  msg.ack();
}

A durable consumer keeps its position on the server. If the process restarts, it continues from the last acknowledged message. A message that isn't acknowledged in time is delivered again.

Check a stream from the CLI:

nats stream info ORDERS

State:
              Messages: 15,234
                 Bytes: 2.1 MiB
        First Sequence: 1 @ 2026-01-15 10:30:00
         Last Sequence: 15,234 @ 2026-01-15 14:22:31

For AI workloads: JetStream works well as a durable log of agent actions. Publish each decision to agent.<agent-id>.actions, and you can replay the exact sequence later when you debug why an agent did something. You can also queue inference requests in a stream, so a model server restart doesn't lose them.

Key-Value store

The KV store is built on JetStream. You get a key-value API, plus per-key history, watchers, and TTL.

import { Kvm } from "@nats-io/kv";

const kv = await new Kvm(nc).create("sessions", {
  history: 5, // keep the last 5 values of each key
  ttl: 60 * 60 * 1000, // 1 hour, in milliseconds
});

await kv.put("user-123", JSON.stringify({
  userId: "user-123",
  role: "admin",
  lastActivity: Date.now(),
}));

const entry = await kv.get("user-123");
console.log("Session:", entry?.string());
console.log("Revision:", entry?.revision); // increases on every write

// Optimistic locking: write only if nobody changed the key since we read it
try {
  await kv.update("user-123", JSON.stringify({ role: "viewer" }), entry!.revision);
} catch {
  console.log("Someone else changed this session first");
}

// Watch for changes
const watch = await kv.watch();
for await (const e of watch) {
  console.log(`${e.key}: ${e.operation}`);
}

Keys can use letters, digits, -, _, /, =, and .. A colon isn't allowed, so the Redis habit of session:user-123 throws an invalid key error. Use dots instead (session.user-123). Dots also let you watch a group of keys with a wildcard, like session.>.

Compared with Redis:

Redis needs Sentinel or Cluster for high availability. A KV bucket replicates like any stream (replicas: 3).
Redis keeps one value per key. KV keeps as many past values as you set in history.
Watching keys in Redis means keyspace notifications or Pub/Sub. KV has watchers built in.
Both have TTL, but only KV gives every write a revision you can use for optimistic locking.

From the CLI:

nats kv put sessions user-456 '{"userId":"user-456"}'
nats kv get sessions user-456
nats kv history sessions user-456

For AI workloads: KV fits conversation state. Store the context window, tool results, and memory under a key like agent.<session-id>.state. History shows how the state changed, watchers let other components react to changes, and the bucket TTL removes abandoned sessions.

Object Store

The Object Store keeps files too large for a single message. It splits each file into chunks stored in a stream, and records a SHA-256 digest so readers can check integrity.

import { readFile } from "node:fs/promises";
import { Objm, StorageType } from "@nats-io/obj";

const store = await new Objm(nc).create("models", {
  storage: StorageType.File,
  description: "Model artifacts",
});

const info = await store.putBlob(
  { name: "classifier/v2.3", description: "Text classifier, trained 2026-01" },
  await readFile("./model-v2.3.bin"),
);
console.log(`Stored ${info.name}: ${info.size} bytes in ${info.chunks} chunks`);
console.log(`Digest: ${info.digest}`);

const data = await store.getBlob("classifier/v2.3"); // Uint8Array, or null

for (const obj of await store.list()) {
  console.log(`${obj.name}: ${obj.size} bytes`);
}

getBlob() loads the whole object into memory. For large files, use store.get(), which returns a readable stream.

From the CLI:

nats object put models ./model-v2.3.bin --name "classifier/v2.3"
nats object get models "classifier/v2.3" --output ./downloaded-model.bin
nats object ls models

For AI workloads: store model configs, LoRA adapters, and smaller model files in the Object Store. Keep the current version in a KV key such as models.classifier.current. Inference servers watch that key and pull the new object when it changes. That gives you a basic model registry without S3. For very large weights, measure first; dedicated object storage may still be the better fit.

Security and multi-tenancy

NATS security is built on accounts, users, and permissions, and it supports decentralized JWT auth for multi-tenant systems.

Users and permissions

# nats-server.conf
authorization {
  users = [
    {
      user: "order-service"
      password: "$2a$11$..."
      permissions: {
        publish: ["orders.>"]
        subscribe: ["orders.*.status"]
      }
    },
    {
      user: "analytics-service"
      password: "$2a$11$..."
      permissions: {
        publish: { deny: [">"] }    # read-only
        subscribe: ["orders.>"]
      }
    }
  ]
}

These permissions cover Core NATS subjects. A service that uses JetStream also needs access to the JetStream API subjects ($JS.API.>, or a narrower set), and a service that sends requests needs to subscribe to its reply inbox (_INBOX.>).

Accounts

Accounts give each tenant a separate namespace:

jetstream: enabled

accounts {
  TEAM_A: {
    users: [{ user: team_a_admin, password: "..." }]
    jetstream: enabled
  }
  TEAM_B: {
    users: [{ user: team_b_admin, password: "..." }]
    jetstream: enabled
  }
}

Team A's orders stream and Team B's orders stream are separate, even on the same cluster. Accounts share data only through explicit exports and imports.

In production, use JWT-based auth managed with the nsc tool. Account and user credentials are signed keys, so the server doesn't need a central user database.

Putting it together for AI

Here's how the pieces fit in an AI agent system:

JetStream streams    agent.*.actions, inference.results
KV buckets           sessions, agent-state, config
Object Store         models, embeddings, documents
Request-reply        inference.chat.query  <->  model servers
Pub/sub              events.*  ->  any number of subscribers

One agent turn:

The user's message is published to chat.<session-id>.input.
The agent loads its state from KV: agent-state key <session-id>.
The agent sends a request to inference.chat.query and waits for the reply.
The agent logs its reasoning to JetStream on agent.<session-id>.actions.
The agent writes its updated context back to the same KV key.
The agent loads tool config from the Object Store: tools/web-search/config.json.
The response is published to chat.<session-id>.output.

All of this runs on one NATS cluster, with one set of runbooks and metrics.

Get started

Install the server and the CLI:

   brew install nats-server nats-io/nats-tools/nats

Or download them from nats.io/download.

Start the server with JetStream:

   nats-server -js

Try it:

   nats server info

   nats stream add TEST --subjects "test.*" --defaults
   nats pub test.hello "Hello NATS!"

   nats kv add config
   nats kv put config app.version "1.0.0"
   nats kv get config app.version

Wrapping up

The point of this post: queuing, caching, and blob storage don't have to be three systems.

When you reach for Kafka for events, Redis for state, and S3 for files, check whether NATS covers the need first. Often it does, and you run one system instead of three.

NATS won't replace Postgres for transactional data. It can replace much of the infrastructure between your services, and that's where most of the operational work is.

Start with Core NATS, add JetStream when you need persistence, and see how far nats-server -js gets you before you add anything else.

Resources

What are you building with NATS? I'd like to hear about it.