NATS frente a Redis Streams: acuses, retención y límite
Dos formas abiertas de mover mensajes entre sistemas. Cómo elegir por acuses, persistencia, permisos, reintentos y prueba de restauración.
Un mensaje de stock qué se procesa dos veces deja de ser detalle técnico cuando duplica una reposición. NATS 2.14.6 y Redis Streams resuelven colas con acuses, retención y consumidores, pero obligan a elegir dónde queda el historial. Esta guía muestra qué dato vive en el broker, qué dato vuelve a PostgreSQL y cómo probar reintentos antes de producción.
Dónde aparece la decisión de colas
La falla aparece cuando un pedido entra por ecommerce, baja stock, genera factura y dispara despacho, todo en segundos. Si un paso cae, el mensaje debe esperar, reintentarse o ir a revisión. La release v2.14.6 de NATS Server fue publicada el 27 de agosto de 2026 y sus notas nombran mejoras y correcciones de JetStream. Redis también empuja la decisión. La release 8.10.1 fue publicada el 17 de agosto de 2026 con urgencia de seguridad, un recordatorio práctico: el broker qué guarda cola también necesita rutina de parcheo, copia y prueba. La cifra de contexto vuelve a ser terrenal: SQL aparece en 58,6 % de la Stack Overflow Developer Survey 2025, de modo que la cola rara vez reemplaza a la base que registra venta, pago y auditoría. En una pyme logística de Godoy Cruz, el objeto que delataba el problema era una etiqueta de despacho impresa dos veces con el mismo número. El sistema había hecho lo qué se le pidió; nadie le enseñó a distinguir reintento de duplicado. El antagonista concreto es el consumidor sin acuse. Lee el mensaje, falla al escribir en la base y deja al equipo discutiendo si el pedido salió.
Cómo funciona por dentro
El flujo técnico tiene seis pasos. Primero, la aplicación publica un evento con identificador, origen, tipo, carga mínima y clave de idempotencia. Segundo, NATS JetStream o Redis Streams guarda el mensaje en una secuencia con política de retención. Tercero, un consumidor toma el mensaje. En JetStream, el servidor administra streams, consumidores, acuses y redelivery. En Redis Streams, la estructura guarda entradas ordenadas y permite grupos de consumidores con pendientes. Cuarto, el consumidor valida formato y escribe el resultado en PostgreSQL. La base guarda pedidos, estados, usuario técnico, intento y error. Quinto, el broker recibe acuse cuando la operación terminó. Sexto, monitoreo revisa cola acumulada, mensajes pendientes, tiempo sin acuse y errores por consumidor. Los permisos separan publicación, consumo y administración. La aplicación publica solo en temas autorizados. El servicio de despacho consume solo su flujo. Operaciones consulta métricas. Sistemas cambia retención, límites y credenciales. Si el broker falla, se frena la entrega; si PostgreSQL falla, no queda registro de negocio; si el backup falla, se pierde la salida auditada. ## Qué se instala o configura primero Para NATS, el primer entregable es un stream con retención definida, consumidor durable, acuse explícito, límite de reintentos y métrica de pendientes. La referencia de configuración ayuda a fijar límites de memoria, archivo y conexiones antes de cargar producción. Para Redis Streams, el primer entregable es un stream por flujo, grupos de consumidores, lectura de pendientes y política de persistencia. La documentación de persistencia de Redis obliga a decidir RDB, AOF o combinación, porque la cola puede sobrevivir o desaparecer según esa elección. Con dólar oficial vendedor a $ 1530, una VM chica para broker y monitoreo cuesta entre USD 18 y USD 45 por mes, entre $ 27.540 y $ 68.850. Ese costo incluye servidor y almacenamiento moderado; horas de diseño, pruebas de carga y observabilidad se miden aparte. UMSA suele empezar con una prueba de diez pedidos: cinco correctos, dos duplicados, dos con error temporal y uno rechazado. La salida esperada es un reporte con mensaje, intento, consumidor, acuse, fila en PostgreSQL y alerta. Recién ahí se conecta facturación, logística o cobranzas.
Dónde se rompe y cómo probarlo
El primer riesgo es procesar sin clave de idempotencia. La señal aparece cuando dos mensajes generan dos filas de negocio. La prueba publica el mismo evento dos veces y confirma que la base conserve una sola operación cerrada. El segundo riesgo es retener menos tiempo que la ventana de soporte. La señal aparece cuando el error se descubre el lunes y el mensaje venció el domingo. La prueba calcula volumen por hora, retención y espacio antes de aceptar el límite. El tercer riesgo es no mirar pendientes. La señal aparece cuando el consumidor figura activo y acumula mensajes sin acuse. La prueba corta el servicio durante cinco minutos y mide reintento, alerta y recuperación. El cuarto riesgo es restaurar solo PostgreSQL. La señal aparece cuando la base vuelve y la cola perdió eventos en tránsito. La prueba levanta broker y base en un entorno aislado, reenvía pendientes y compara conteos. NATS suele encajar cuando pesan streams, acuses y operación distribuida. Redis Streams encaja cuando el equipo ya opera Redis y acepta cuidar persistencia con disciplina. La cola que sirve es la que muestra qué pasó con cada mensaje.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.