NATS 2.14 en pymes: colas, acuses y reintentos
Como separar eventos internos con NATS y JetStream: publicacion, acuses, permisos, respaldo y prueba de consumidores antes de produccion.
Cinco scripts que preguntan cada minuto pueden costar mas que una cola de mensajes con acuses y reintentos. En una pyme, el polling entre facturacion, turnos, stock y notificaciones carga bases, duplica reglas y esconde errores. NATS 2.14 permite publicar eventos livianos y persistirlos con JetStream. Esta guia explica cuando usarlo, donde vive cada mensaje y como probar que un consumidor puede caer y volver.
Donde aparece el costo del polling
La cifra que ordena la decision viene del release: NATS v2.14.0 fue publicado el 30 de abril de 2026 y el repositorio tiene licencia Apache-2.0. La eleccion conviene cuando varias aplicaciones necesitan enterarse de un cambio sin consultar la misma tabla cada pocos segundos.
Un evento perdido queda oculto hasta que un cliente llama.
La escala global muestra por que las colas volvieron a la conversacion operativa. La encuesta anual de CNCF releva adopcion de plataformas nativas de nube y practicas de produccion. En una clinica privada de Godoy Cruz, un turno cancelado, una factura emitida y una orden de laboratorio deben moverse una vez, con acuse y registro.
El cron que todos temen tocar
El antagonista es el cron de madrugada que revisa cambios, manda avisos y reintenta todo junto si el proveedor estuvo caido. El encargado de sistemas puede tener un patch panel numerado con marcador negro y una etiqueta vieja sobre el servidor de laboratorio. Ese detalle muestra el punto operativo: cuando todo depende de un script, nadie sabe si fallo la consulta, el envio o el reintento.
La documentacion de JetStream define el componente persistente de NATS: guarda mensajes en streams, permite consumidores y conserva estado de entrega. La pagina de consumers explica durables, acuses y politicas de entrega. Esa separacion permite que una aplicacion publique "turno cancelado" y otra lo procese despues, sin bloquear la base principal.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, la aplicacion de origen publica un evento con identificador, tipo, fecha y cuerpo. Segundo, NATS recibe el mensaje y lo enruta por subject. Tercero, JetStream guarda el mensaje en un stream con retencion y replicas configuradas. Cuarto, un consumidor durable lee el evento y confirma con ack cuando termino. Quinto, PostgreSQL guarda registros estructurados, estados de negocio y auditoria final. Sexto, Prometheus o el monitoreo de NATS muestra mensajes pendientes, reintentos y errores. Septimo, el backup copia configuracion, streams persistentes si aplican y base de negocio, y se prueba apagando un consumidor.
NATS recibe mensajes y entrega eventos a suscriptores. JetStream recibe eventos y entrega persistencia, acuses y reentrega. PostgreSQL guarda el resultado verificable de la operacion: turno, factura, pedido, estado y usuario. El monitoreo recibe metricas y entrega alertas. Si falla NATS, los servicios dejan de intercambiar eventos nuevos. Si falla un consumidor, JetStream retiene pendiente hasta que vuelva o hasta que venza la politica elegida.
Los permisos se separan por subject. Facturacion publica comprobantes. Turnos publica altas y cancelaciones. Laboratorio consume pedidos. Mesa de ayuda lee errores. Un proveedor externo solo recibe eventos del servicio asignado. La baja de un consumidor se prueba con credenciales y una denegacion registrada.
Que se instala o configura primero
La pila inicial usa NATS 2.14, JetStream, TLS, usuarios por servicio, subjects nombrados, monitoreo, PostgreSQL 18 para estados finales y backup diario. El piloto cuesta entre USD 1.400 y USD 4.200, entre ARS 1,98 y 5,94 millones al dolar vendedor oficial de $1.414 informado por Bluelytics. Incluye tres eventos, dos consumidores, permisos, tablero de pendientes y prueba de caida.
El plazo va de tres a cinco semanas. UMSA suele pedir un entregable verificable: evento publicado desde la aplicacion, stream creado, consumidor durable, ack registrado, reintento forzado, alerta por cola acumulada y restauracion de configuracion. El costo no incluye reescribir sistemas viejos ni cambiar contratos con proveedores.
El primer caso debe ser chico. "Turno cancelado" contiene id de turno, paciente anonimo, fecha, origen y motivo. El contrato del evento queda escrito con campos obligatorios, version y ejemplo JSON. El consumidor de notificaciones lo toma, envia aviso y confirma ack. Si el canal externo falla, el mensaje queda pendiente y la alerta muestra cantidad y antiguedad.
Donde se rompe y como probarlo
Primer riesgo: evento sin idempotencia. La senal aparece cuando el mismo mensaje crea dos acciones. La prueba publica dos veces el mismo id y verifica un solo cambio en PostgreSQL. Segundo riesgo: ack temprano. La senal es un mensaje confirmado antes de escribir el resultado. La prueba corta el consumidor entre lectura y escritura.
Tercer riesgo: retencion mal configurada. La senal aparece cuando una caida de una hora borra pendientes. La prueba detiene el consumidor mas tiempo que la ventana prevista y revisa cantidad. Cuarto riesgo: permisos por subject demasiado amplios. La prueba intenta publicar desde facturacion en un subject de laboratorio. Una cola util deja una pregunta simple: que mensaje queda pendiente ahora.