NATS vs Kafka vs AWS SQS: un framework de decisión para ingenieros

Ya leíste cómo encajan los subjects de NATS, los streams de JetStream, los mirrors de KV, las proyecciones CQRS y la observabilidad en las partes 1–5 de esta serie. También viste dónde se ubica un bus de mensajes en una arquitectura en crecimiento en Las piezas del diseño de software moderno y eficaz. La pregunta que queda es directa: ¿cuándo es NATS el bus adecuado y cuándo conviene recurrir a Kafka o AWS SQS?

Este artículo es un framework de decisión, no una competencia en la que solo puede haber un ganador. Las afirmaciones que siguen se basan en documentación oficial. Cuando una fila refleja criterio de ingeniería —por ejemplo, la carga operativa típica de un equipo pequeño— se indica que es una inferencia.

Investigación basada en docs.nats.io, la documentación de Apache Kafka y la documentación de AWS SQS el July 6, 2026.

TL;DR

• Core NATS ofrece pub/sub en memoria con entrega como máximo una vez, request/reply y queue groups: es excelente para mensajería interna en vivo cuando los suscriptores están conectados.
• JetStream (integrado en nats-server) agrega streams durables, replay, KV y semántica de entrega al menos una vez o exactamente una vez mediante configuración explícita: la respuesta de NATS al desacoplamiento temporal sin adoptar una plataforma independiente.
• Kafka es un log de eventos distribuido: los topics están particionados, se retienen y permiten replay por diseño; el procesamiento de streams (Kafka Streams, Connect y su ecosistema) es la principal razón por la que los equipos lo adoptan.
• SQS es una cola punto a punto administrada en AWS: no hay que operar un clúster, las colas estándar ofrecen entrega al menos una vez y las FIFO ofrecen procesamiento exactamente una vez cuando necesitas orden; no es un log ni ofrece pub/sub nativo.
• Elige según los síntomas (consumidores desconectados, ventana de replay, forma del fan-out, tolerancia a la dependencia de un proveedor cloud y quién opera el clúster), no según clasificaciones de latencia sin fuentes.

Qué aprenderás aquí

• En qué se diferencian NATS (Core + JetStream), Kafka y SQS en ocho dimensiones de ingeniería
• Cuándo gana NATS, incluidos los patrones de la parte 1 (request/reply, queue groups), la parte 2 (streams/consumidores), la parte 3 (KV) y la parte 4 (infraestructura interna de conexión)
• Cuándo gana Kafka: retención de logs, particiones y procesamiento de streams
• Cuándo gana SQS: desacoplamiento nativo de AWS sin operar brokers
• Un flujo de decisión en ASCII y tablas de síntoma → opción adecuada que puedes pegar en un ADR

Contexto de la serie: Parte 1 · Parte 2 · Parte 3 · Parte 4 · Parte 5

Tres primitivas diferentes

Antes de la tabla comparativa, aclaremos qué es cada sistema:

  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 no es un sustituto directo de Kafka ni del pub/sub de NATS. AWS documenta SQS como un mecanismo de desacoplamiento mediante colas; para hacer fan-out a muchos suscriptores, normalmente se combina SNS → SQS (descripción general de SQS).

Dimensiones de comparación

Semántica de entrega

Nota de ingeniería: «Exactamente una vez» suele significar «exactamente una vez bajo los modelos de falla documentados». La documentación de Kafka aclara que la entrega de extremo a extremo exactamente una vez hacia sistemas externos requiere la cooperación de esos sistemas.

Modelo de persistencia

Complejidad operativa

La documentación de NATS describe nats-server como de «menos de 20 MB» (¿Qué es NATS?). Eso habla de su tamaño de despliegue, no de su rendimiento.

Fan-out vs cola

Replay

Perfil de latencia (solo cualitativo)

La documentación oficial describe mecanismos, no clasificaciones de latencia entre proveedores. Razona de forma cualitativa:

En SQS, el polling frente al long polling y el visibility timeout afectan directamente la demora observada de extremo a extremo (ciclo de vida del mensaje): ajústalos antes de cambiar de broker.

Multi-cloud / portabilidad

Modelo de costos (matiza cada afirmación)

No extrapoles cuál es la opción «más barata» solo a partir de los precios de lista: modela las solicitudes, el tamaño del payload, los GB-mes de retención y el tiempo de ingeniería.

Cuándo gana NATS

NATS encaja cuando la mensajería es infraestructura interna —de servicio a servicio, de edge a cloud, plano de control— y quieres un runtime liviano que abarque tanto el pub/sub de Core como la durabilidad de JetStream.

  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

Cuándo NATS es una opción predeterminada menos conveniente (inferencia):

• Analítica de varios equipos sobre meses de historial inmutable con herramientas SQL sobre streams
• El estándar de la organización ya es Kafka Connect + Flink + schema registry
• El equipo no tiene ninguna disposición para operar un broker de mensajes: SQS/Lambda puede ganar solo por razones operativas

Cuándo gana Kafka

Kafka encaja cuando el log en sí es el producto: ingesta de alto volumen, muchos consumidores posteriores a distintas velocidades, retención prolongada y procesamiento de streams.

  Log-centric analytics (Kafka sweet spot)

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

Compromisos que debes aceptar: cantidad de brokers, planificación de particiones, dashboards de lag de consumidores y disciplina para las actualizaciones. La documentación de diseño de Kafka apunta a «streams de eventos de alto volumen» y «cargas periódicas de datos desde sistemas desconectados», no a RPC interno minimalista.

Cuándo gana SQS

SQS encaja cuando las cargas de trabajo son nativas de AWS, tienen forma de cola y quieres que AWS se encargue de la disponibilidad.

  AWS glue (SQS sweet spot)

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

Cuándo SQS es una opción predeterminada menos conveniente (inferencia):

• Pub/sub nativo con decenas de suscriptores activos en el mismo subject
• Replay desde offsets históricos arbitrarios para nuevos consumidores
• Despliegue principal multi-cloud o local
• Request/reply entre microservicios internos (usa HTTP/gRPC o NATS Core en su lugar)

Flujo de decisión

                        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) │
                         └─────────┘  └──────────┘

Implementación concreta: guía de selección basada en síntomas

Usa esta sección como apéndice de un ADR. Cada fila relaciona un síntoma en producción con una opción predeterminada razonable y el primer parámetro de configuración que debes verificar.

Síntoma → opción adecuada (patrón de mensajería)

Síntoma → opción adecuada (restricciones operativas)

Ejemplos mínimos de integración (prueba básica de la elección)

NATS JetStream — evento durable de pedido (del contexto de la serie):

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

Kafka — topic con retención explícita (ilustrativo):

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

SQS — visibility timeout ajustado al handler (AWS CLI):

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

Si no puedes explicar qué fila de las tablas anteriores corresponde a tu síntoma, aún no estás listo para elegir un broker: define primero la garantía de entrega y la ventana de retención.

Arquitecturas híbridas (comunes en la práctica)

Los sistemas reales combinan herramientas:

Las soluciones híbridas agregan puntos de integración operativos: documenta quién se encarga de los reintentos, la DLQ y el esquema en cada límite.

Errores comunes

1. Elegir Kafka para RPC interno. Request/reply no es el caso ideal de Kafka; usa HTTP/gRPC o NATS Core.
2. Elegir SQS para pub/sub. Usa fan-out de SNS o un bus con subjects/topics nativos.
3. Usar Core NATS para eventos de facturación. Entrega como máximo una vez + suscriptores desconectados = pérdida silenciosa (¿Qué es NATS?).
4. Esperar replay de SQS. Una vez eliminado un mensaje, desaparece: no es un log.
5. Ignorar la idempotencia. La entrega al menos una vez es la opción predeterminada en casi todas partes.
6. Elegir según benchmarks. El marketing de los proveedores y los artículos de blog desactualizados no representan la topología de tu red.

Cómo encaja esto en la serie

Para conocer los niveles de la arquitectura (outbox, proyecciones, búsqueda), consulta Las piezas del diseño de software moderno y eficaz.

Fuentes

• ¿Qué es NATS? — QoS, Core vs JetStream, escala de despliegue
• Core NATS — pub/sub con entrega como máximo una vez
• JetStream — streams, retención, replay, replicación, KV
• Almacén clave/valor de JetStream — buckets de KV y semántica de watch
• Apache Kafka — Introducción — topics, particiones, grupos de consumidores, APIs
• Apache Kafka — Diseño — persistencia del log, particionamiento del productor, consumo por pull
• Apache Kafka — Semántica de entrega de mensajes — entrega al menos una vez, exactamente una vez, transacciones
• Amazon SQS — ¿Qué es Amazon SQS? — ciclo de vida de la cola, comparación con SNS
• Amazon SQS — Tipos de cola — garantías de las colas estándar vs FIFO
• Amazon SQS — Dead-letter queues — redrive y maxReceiveCount
• Precios de Amazon SQS — facturación por solicitud y división de payloads en fragmentos