Corredores de mensajes

1) Por qué los corredores de mensajes

• Amortiguación y suavización de picos, retroexcavadora.
• Escala de lectura/escritura de forma independiente.
• Observabilidad y reproducción (replay) de eventos.
• Patrones arquitectónicos: event-driven, CQRS, event sourcing, outbox/inbox.

2) Modelos y términos básicos

2. 1 Kafka (modelo de guarida)

Topic → lotes (registros ordenados) → offsets en los consumers.
Grupo Consumidor: paralelismo de lectura, equilibrio de partidos.
Retiro en tiempo/volumen; Compacto por clave.
Semántica: mínima - en-least-once, cuando se configura - effectively exactly-once (productores idempotentes + transacciones).
Orden: garantizado dentro del partido.

2. 2 NATS (temas/subjectos, baja latencia)

Subject (tema) con jerarquía y wildkarts ('foo.', 'foo. >`).
Modos: pub/sub, queue-groups (fan out con distribución de trabajo), request-reply (RPC rápido).
Core NATS es una latencia efímera, ultra baja; JetStream - persistencia/retoque/repeticiones.
Orden: mejor-esfuerzo, sin una fuerte garantía global; con JetStream - Ordenar en stream, pero raras reordenaciones son posibles cuando hay fallas.

3) Semánticas de entrega y coherencia

Idempotencia y dedoup es responsabilidad de la aplicación/xink, incluso con «exactly-once» en Kafka.

4) Orden, partido y llaves

Kafka

La selección de la clave de mensaje determina el lote → un orden local fuerte.
Ключи: `aggregate_id`, `tenant_id`, `order_id`. Evite las llaves calientes.
Equilibrio: N partes ≈ nivel de paralelismo de lectura.

NATS

En Core, el balance hace queue-group.
En JetStream, Stream está chardineado por subjects; énfasis en el fan-out/fan-in amplio con poca demora.

5) Retiro, réplica y compacción

Kafka

Retention: `retention. ms/bytes`.
Compaction: almacena el «último valor por clave» (adecuado para snapshots/cachés/sagas).
Replay: cualquier consumer puede «enrollar» los offsets.

JetStream

Streams: fichero/membrana backend, política de retención por tiempo/bytes/mensajes de cola-wu.
Consumidores: pull/push, durable/ephemeral, filtro por prefijos subject.
Replay: redelivery o reading desde el principio/offset-like (sequence).

6) Transacciones, outbox y coherencia

Kafka

Idempotent Producer (`enable. idempotence = true '): protección contra tomas.
Transactions: registro atómico de varios lotes + commits consumer-offsets → patrón read-process-write sin «agujeros».
Transactional Outbox: registra un evento comercial y una línea de outbox en una sola transacción de BD, el worker publica en Kafka.

NATS

No hay transacciones «entre líneas» como en Kafka; use outbox/inbox y consumers idempotentes (llaves, dedup stor).

7) RPC y solicitud de respuesta

Kafka para RPC es incómodo (alto overhead, orden/respuestas son más difíciles). Utilice comandos/eventos asíncronos.
NATS: ideal para request-reply (milisegundos, corelación, timeouts).

go resp, err:= nc. Request("profile. get", []byte(`{"id":42}`), 200time. Millisecond)

8) Operación y topologías

8. 1 Kafka

Cluster: brokers + ZooKeeper (antes de versiones anteriores) o KRaft (nuevo metadato).
Replicación: RF≥3 por zona, controladores ISR/.
Multirregión: MirrorMaker 2/Cluster Linking; activo-pasivo/activo-activo con políticas de conflicto.
Capacidad de disco/red: contar desde 'throughput × retention × replicas'.

8. 2 NATS

Cluster: muchos nodos, super-cluster (georredistribución), leafnodes para periféricos/edge.
JetStream: colocación de streams por conjuntos de nodos (placement), replicación (R = 1.. 5).
WAN: previsiblemente bajos retrasos, federación fácil.

9) Seguridad

Kafka

TLS (mTLS), SASL: SCRAM, OAuthBearer.
ACL en topics/grupos/transacciones.
Cifrado en reposo (OS/unidades) + directivas de red.

NATS

nkey/JWT identidades, operador-cuentas, per-subject ACL.
mTLS entre nodos y clientes.
Aislamiento de inquilinos (cuentas) + límites.

10) Observabilidad y métricas operativas

Kafka

Брокер: `BytesIn/Out`, `RequestQueue`, `UnderReplicatedPartitions`, GC/FS stats.
Topic/lote: 'logEndOffset', lag de consumo (crítico).
Productor/consumer: retrai, 'batch. size`, `linger. ms`, `fetch. min. bytes ', errores.
Herramientas: JMX, Control de crucero (re-balance), Registro de Schema.

NATS/JetStream

Servidor: conn/msgs/sec, RTT, CPU/nat, slow consumer detección.
JetStream: per stream/consumer — lag, redeliveries, acks, storage bytes.
Monitoreo: endpoint incorporado, nsc/adm-CLI, dashboards.

11) Rendimiento y afinación

Kafka

Grandes batches y 'linger. ms 'mejoran throughput y comprimen p99.
La compresión (lz4/zstd) ahorra red/disco.
num. partitions por número de consumidores/núcleos, pero no inflexibles (overhead).
Discos: NVMe es preferible XFS/EXT4 con 'noatime'.

NATS

Mensajes pequeños, muchas conexiones - la norma; mantenga el queue groups «ancho».
JetStream: tune `max_ack_pending`, pull vs push, size of batches.
Backpressure: `FlowControl`, `IdleHeartbeat`, server-side limits.

12) Patrones de integración

Outbox/Inbox (tanto en Kafka como en NATS).
SAGA: orquestación por eventos; dedoup por 'saga _ id + step'.
Change Data Capture (CDC): Debezium → Kafka; en NATS, es un patrón de "publisher from DB desencadenantes/logs'.
Stream processing: Kafka Streams/Flink/Spark; en NATS: procesadores/funciones de terceros, consumidores de JetStream.
Dead Letter Queue (DLQ) y políticas retry (retroceso exponencial + jitter).

13) Ejemplos de configuraciones

13. 1 Kafka: creación de un topic y productor

bash kafka-topics. sh --create --topic orders \
--partitions 12 --replication-factor 3 \
--config cleanup. policy=delete \
--config retention. ms=604800000 # 7d

properties producer. properties bootstrap. servers=broker:9092 acks=all enable. idempotence=true batch. size=65536 linger. ms=10 compression. type=zstd

13. 2 Kafka Streams: tratamiento idempotente (boceto)

java builder. <String, Order>stream("orders")
.groupByKey()
.aggregate(/... /)
.toStream()
.to("orders-agg");

13. 3 NATS JetStream: stream + consumer (nats CLI)

bash nats stream add ORDERS --subjects "orders. " --retention limits \
--storage file --max-bytes 100GB --replicas 3 --discard old

nats consumer add ORDERS ORDERS-WORKERS --filter "orders. created" \
--deliver pull --ack explicit --max-deliver 6 --backoff "1s,5s,30s,2m"

13. 4 NATS Request-Reply (Go)

go nc, _:= nats. Connect("tls://nats:4222", nats. Secure(tlsConf))
sub, _:= nc. QueueSubscribe("calc. sum", "workers", func(m nats. Msg) {
//... process...
m. Respond([]byte("42"))
})

14) Selección de Kafka vs NATS: referencia rápida

Necesita un replay, retoque de larga duración, compactación, procesos de streaming pesados → Kafka.
Necesita RPC rápido, fan out/fan in con microlatencia, operación simple, edge/IoT → NATS (Core).
Se necesita persistencia + fan out, pero sin la pesada «guarida» de la plataforma → NATS JetStream.
Orden estricto sobre la clave y la transacción → Kafka.

15) Planificación de la capacidad (simplificada)

Kafka

1. Ancho de banda: 'inbound _ MBps × RF × retention_days × 86400' unidades →.
2. Lotes: 'target _ concurrency' × stock 1. 5–2×.
3. Red: p99 + replicación + producción compresión.

NATS/JetStream

1. Mensajes/segundos y tamaño medio → throughput.
2. Retention×replicas → storage.
3. Límites de consumo (ack-pending, redeliveries), CPU sobre serialización.

16) Operación segura: lista de verificación

• TLS/mTLS está habilitado, los secretos se rotan.
• ACL/cuentas/cuotas (per-tenant).
• Idempotencia en consumers, DLQ y retraídas con jitter.
• Monitoreo de lag/throughput/errores; alertas a la URP (Kafka), la tormenta redelivery (NATS).
• Capacity dashboards: partes, almacenamiento, p99.
• Pruebas de falla de nodos/zonas, días de juego, réplica/backfill.
• Se han documentado las claves de lote y esquema (Schema Registry/JSON Schema).
• Las políticas de retransmisión/compacción/TTL están alineadas con el cumplimiento.
• Las versiones de los corredores/clientes se actualizan regularmente; se ha comprobado la compatibilidad del protocolo wire.

17) Anti-patrones

Una llave caliente (todos los eventos de un único ID) → un flujo «hirviendo». Buffering/buffering.
Retraídas sin idempotencia → efectos de toma.
Mensajes enormes (MB-docenas) → fragmentación/pausa de GC. Almacenar payload en objeto, enviar enlaces.
Mezclar RPC y streaming en Kafka → un ciclo de vida/orden complejo.
JetStream como «DWH a largo plazo» → no es el propósito; almacene durante mucho tiempo en las mesas de objetos/columnas.
No hay DLQ → los mensajes «venenosos» giran indefinidamente.
Retiro olvidado → los discos están llenos, deteniendo el clúster.

18) FAQ

P: ¿Se puede hacer «exactly-once» al final de la paipline?
R: En la práctica - efectivamente sí: Kafka (productor idempotente + transacciones) y xinki idempotente (clave, upsert). En NATS: a través de la idempotencia/dedoup en la aplicación.

P: ¿Qué elegir para un millón de pequeños RPC/sec?
A: NATS Core: microlatencia, request-reply, connects ligeros y queue-groups.

P: ¿Necesita un compacto y un snapshot de estado?
A: Kafka с `cleanup. policy = compact ', clave = agregado/recurso.

P: ¿Cómo lidiar con la laguna?
R: Aumente el número de lotes/workers, reduzca el tiempo de procesamiento, batches y prefetch, optimice la deserialización, refuerce verticalmente los corredores/discos.

P: ¿Multirregión y DR?
A: Kafka - MirrorMaker 2/Cluster Linking, activo-pasivo con RPO≈sekundy. NATS — supercluster/leafnodes; JetStream espejado/réplica por zona.

19) Resultados

Kafka y NATS cierran diferentes modos: Kafka son registros de eventos duraderos, alto throughput, transaccionalidad y replay; NATS es un bus ultraligero para latencias bajas, RPC y fan out simple, con JetStream para persistencia. Elija entre la semántica de envío, el orden y el retén, la latencia y los costos operativos. Diseñe llaves/lotes, retoque, DLQ y observabilidad, y su arquitectura de eventos será predecible, escalable y confiable.