NATS 2.14 en pymes: colas, acuses y reintentos
Como separar eventos internos con NATS y JetStream: publicación, acuses, permisos, respaldo y prueba de consumidores antes de producción.
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 guía explica cuando usarlo, donde vive cada mensaje y como probar que un consumidor puede caer y volver.
Dónde aparece el costo del polling
La cifra que ordena la decisión 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 producción. 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 documentación de JetStream define el componente persistente de NATS: guarda mensajes en streams, permite consumidores y conserva estado de entrega. La página de consumers explica durables, acuses y políticas de entrega. Esa separacion permite que una aplicación publique "turno cancelado" y otra lo procese después, sin bloquear la base principal.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, la aplicación 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 auditoría final. Sexto, Prometheus o el monitoreo de NATS muestra mensajes pendientes, reintentos y errores. Septimo, el backup copia configuración, 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 operación: 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 política 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.
Qué 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 dólar 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 aplicación, stream creado, consumidor durable, ack registrado, reintento forzado, alerta por cola acumulada y restauración de configuración. 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, versión 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.
Dónde se rompe y cómo probarlo Primer riesgo: evento sin idempotencia.
La señal 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 señal es un mensaje confirmado antes de escribir el resultado. La prueba corta el consumidor entre lectura y escritura. Tercer riesgo: retencion mal configurada. La señal 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.