NATS vs Kafka vs AWS SQS: A Decision Framework for Engineers

You have read how NATS subjects, JetStream streams, KV mirrors, CQRS projections, and observability fit together in Parts 1–5 of this series. You have seen where a message bus sits in a growing architecture in The Pieces of Modern, Effective Software Design. The remaining question is blunt: when is NATS the right bus, and when should you reach for Kafka or AWS SQS instead?

This article is a decision framework, not a winner-takes-all shootout. Claims below are tied to official documentation. Where a row reflects engineering judgment — for example, typical ops burden in a small team — that is labeled as inference.

Researched against docs.nats.io, Apache Kafka documentation, and AWS SQS documentation on July 6, 2026.

TL;DR

• Core NATS is at-most-once, in-memory pub/sub with request/reply and queue groups — excellent for live internal messaging when subscribers are online.
• JetStream (built into nats-server) adds durable streams, replay, KV, and at-least-once / opt-in exactly-once semantics — the NATS answer to temporal decoupling without adopting a separate platform.
• Kafka is a distributed event log: topics are partitioned, retained, and replayable by design; stream processing (Kafka Streams, Connect, ecosystem) is the main reason teams adopt it.
• SQS is a managed point-to-point queue on AWS: no cluster to run, at-least-once standard queues, FIFO with exactly-once processing when you need ordering — not a log and not native pub/sub.
• Pick on symptoms (offline consumers, replay window, fan-out shape, cloud lock-in tolerance, who runs the cluster), not on unsourced latency leaderboards.

What You Will Learn Here

• How NATS (Core + JetStream), Kafka, and SQS differ on eight engineering dimensions
• When NATS wins — including patterns from Part 1 (request/reply, queue groups), Part 2 (streams/consumers), Part 3 (KV), and Part 4 (internal plumbing)
• When Kafka wins — log retention, partitions, stream processing
• When SQS wins — AWS-native decoupling without broker operations
• An ASCII decision flow and symptom → fit tables you can paste into an ADR

Series context: Part 1 · Part 2 · Part 3 · Part 4 · Part 5

Three Different Primitives

Before the comparison table, align on what each system is:

  Core NATS          JetStream                 Kafka                    SQS
  ─────────          ─────────                 ─────                    ───
  Pub ──► Sub        Pub ──► Stream ──► Cons  Pub ──► Topic (log)      Pub ──► Queue ──► Worker
  (live only)        (persist + replay)        ──► many consumers       (point-to-point)
                                               (offsets, retention)

SQS is not a drop-in substitute for Kafka or NATS pub/sub. AWS documents SQS as decoupling via queues; fan-out to many subscribers typically pairs SNS → SQS (SQS overview).

Comparison Dimensions

Delivery semantics

Engineering note: “Exactly-once” anywhere usually means “exactly-once under documented failure models.” Kafka’s docs are explicit that end-to-end exactly-once to external systems requires cooperation with those systems.

Persistence model

Operations complexity

NATS documents nats-server as “less than 20 MB” (What is NATS?). That speaks to deployment footprint, not a performance claim.

Fan-out vs queue

Replay

Latency profile (qualitative only)

Official docs describe mechanisms, not cross-vendor latency rankings. Reason qualitatively:

For SQS, polling vs long polling and visibility timeout directly affect observed end-to-end delay (message lifecycle) — tune these before swapping brokers.

Multi-cloud / portability

Cost model (qualify every claim)

Do not extrapolate “cheapest” from list prices alone — model requests, payload size, retention GB-months, and engineer time.

When NATS Wins

NATS fits when messaging is internal infrastructure — service-to-service, edge-to-cloud, control plane — and you want one lightweight runtime that spans Core pub/sub and JetStream durability.

  Internal mesh style (NATS sweet spot)

  API ──request/reply──► Authz svc
    │
    └──publish──► orders.created ──► [billing worker]
                              └──► [analytics projector]
         JetStream stream (optional durability)
              └──► KV mirror ──watch──► indexer

When NATS is a weaker default (inference):

• Multi-team analytics on months of immutable history with SQL-over-streams tooling
• Organization standard is already Kafka Connect + Flink + schema registry
• Team has zero appetite to operate any message broker — SQS/Lambda may win on ops alone

When Kafka Wins

Kafka fits when the log itself is the product — high-volume ingestion, many downstream consumers at different speeds, long retention, stream processing.

  Log-centric analytics (Kafka sweet spot)

  Producers ──► topic (partitions P0..Pn, replicated)
                    │
        ┌───────────┼───────────┬──────────────┐
        ▼           ▼           ▼              ▼
   Warehouse    Flink job   Search sink    Audit archive
   (Connect)    (Streams)   (Connect)      (long retention)

Tradeoffs to accept: broker count, partition planning, consumer lag dashboards, and upgrade discipline. Kafka’s own design docs target “high volume event streams” and “periodic data loads from offline systems” — not minimal internal RPC.

When SQS Wins

SQS fits when workloads are AWS-native, queue-shaped, and you want AWS to own availability.

  AWS glue (SQS sweet spot)

  API Gateway / ALB ──► SQS ──► Lambda / ECS worker
                      │
                      └── on failure ──► DLQ ──► redrive / alarm

When SQS is a weaker default (inference):

• Native pub/sub with dozens of live subscribers on the same subject
• Replay of arbitrary historical offsets for new consumers
• Multi-cloud or on-prem primary deployment
• Request/reply between internal microservices (use HTTP/gRPC or NATS Core instead)

Decision Flow

                        Start: async communication needed
                                      │
                                      ▼
                    ┌─────────────────────────────────────┐
                    │ Must run outside AWS or multi-cloud? │
                    └─────────────────────────────────────┘
                          │ yes                    │ no
                          ▼                        ▼
              ┌───────────────────┐      ┌──────────────────────┐
              │ Need log retention │      │ Queue + AWS services  │
              │ + stream ecosystem│      │ only?                 │
              └───────────────────┘      └──────────────────────┘
                 │ yes      │ no              │ yes      │ no
                 ▼          ▼                 ▼          ▼
            ┌────────┐  ┌─────────────────────────┐   ┌────────┐
            │ Kafka  │  │ Subscribers often offline │   │ SQS    │
            │        │  │ or need replay/KV/RPC?    │   │ (+SNS  │
            └────────┘  └─────────────────────────┘   │ if fan-│
                              │ yes      │ no        │ out)   │
                              ▼          ▼           └────────┘
                         ┌─────────┐  ┌──────────┐
                         │JetStream│  │Core NATS │
                         │(+ Core  │  │(live fan-│
                         │ as RPC) │  │out, RPC) │
                         └─────────┘  └──────────┘

Concrete Implementation: Symptom-Based Selection Guide

Use this section as an ADR appendix. Each row maps a production symptom to a reasonable default and the first config knob to verify.

Symptom → fit (messaging pattern)

Symptom → fit (operational constraints)

Minimal wiring examples (selection smoke test)

NATS JetStream — durable order event (from series context):

nats stream add ORDERS \
  --subjects "orders.>" \
  --storage file \
  --retention limits \
  --max-age 7d \
  --replicas 3

Kafka — topic with explicit retention (illustrative):

# server.properties / topic config
log.retention.hours=168
min.insync.replicas=2

SQS — visibility timeout aligned to handler (AWS CLI):

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes VisibilityTimeout=300

If you cannot articulate which row in the tables above matches your symptom, you are not ready to pick a broker — define the delivery guarantee and retention window first.

Hybrid Architectures (Common in Practice)

Real systems mix tools:

Hybrids add operational seams — document ownership of retry, DLQ, and schema at each boundary.

Common Mistakes

1. Choosing Kafka for internal RPC. Request/reply is not the Kafka sweet spot; use HTTP/gRPC or NATS Core.
2. Choosing SQS for pub/sub. Use SNS fan-out or a bus with native subjects/topics.
3. Using Core NATS for billing events. At-most-once + offline subscribers = silent loss (What is NATS?).
4. Expecting SQS replay. Once deleted, it is gone — not a log.
5. Ignoring idempotency. At-least-once is the default almost everywhere.
6. Benchmark shopping. Vendor marketing and stale blog posts are not your network topology.

How This Fits the Series

For the architectural ladder (outbox, projections, search), see The Pieces of Modern, Effective Software Design.

Sources

• What is NATS? — QoS, Core vs JetStream, deployment scale
• Core NATS — at-most-once pub/sub
• JetStream — streams, retention, replay, replication, KV
• JetStream Key/Value Store — KV buckets and watch semantics
• Apache Kafka — Introduction — topics, partitions, consumer groups, APIs
• Apache Kafka — Design — log persistence, producer partitioning, pull consumption
• Apache Kafka — Message Delivery Semantics — at-least-once, exactly-once, transactions
• Amazon SQS — What is Amazon SQS? — queue lifecycle, SNS comparison
• Amazon SQS — Queue types — standard vs FIFO guarantees
• Amazon SQS — Dead-letter queues — redrive and maxReceiveCount
• Amazon SQS pricing — per-request metering and payload chunking