NATS 2.14 en pymes: colas, permisos y reintentos
NATS sirve para separar integraciones sin llenar el ERP de polling. Cómo usar subjects, JetStream, permisos, backup y pruebas de reintento en una pyme.
Tres integraciones que preguntan cada minuto pueden costar más soporte que un broker pequeño bien probado. NATS 2.14 permite separar avisos, eventos y reintentos sin meter cada consulta dentro del ERP. En una pyme con facturación, stock y mesa de ayuda, esta guía muestra dónde vive cada dato, quién puede publicar o leer mensajes y qué prueba confirma que una falla vuelve sin duplicar trabajo.
Dónde aparece la cola que nadie nombró
El síntoma se ve cuando una factura validada en el ERP tarda en llegar al sistema de tickets, o cuando un depósito cambia stock y el tablero se entera tarde. El antagonista es el polling repetido, escondido en tareas cron que nadie lista. Un monitor APC con cinta de papel pegada al rack suele ser el único testigo de esos horarios. La cifra que corrige la escena viene del propio proyecto. El repositorio de nats-server registraba 20.264 estrellas y licencia Apache-2.0 al 18 de julio, y la última versión publicada era v2.14.3, del 29 de junio de 2026. Esa actividad muestra una comunidad viva alrededor del componente. El dato global empuja la misma conclusión. GitHub informó en su Octoverse: se suma un desarrollador nuevo cada segundo. Cuando las integraciones crecen a ese ritmo, el contrato entre sistemas vale más que el script rápido del viernes. La decisión técnica queda clara cuando se dibuja el trayecto de un evento y se deja de perseguir pantallas.
Cómo funciona por dentro
El flujo empieza con una aplicación que publica un mensaje en un subject, por ejemplo factura.validada o stock.movido. NATS Core entrega el mensaje a los suscriptores activos mediante pub/sub, según explica la documentación de core NATS. Si el consumidor está conectado, procesa el aviso en el momento. JetStream agrega persistencia. El servidor captura mensajes en streams y permite reproducirlos después, aplicar límites de edad, tamaño o cantidad y elegir políticas de retención, según la guía de JetStream. Ese punto cambia el flujo operativo: un corte de red deja de borrar el evento y pasa a generar una deuda procesable. PostgreSQL guarda el dato de negocio: factura, ticket, producto, usuario y estado. NATS guarda el aviso que mueve ese dato entre servicios. Un worker lee el mensaje, verifica idempotencia con una clave única, actualiza la base y marca el procesamiento. Si falla, el mensaje queda pendiente o vuelve según la configuración del consumidor. El tablero muestra cantidad de pendientes, errores por subject y último procesamiento correcto. Los permisos se escriben por usuario y por subject. La documentación de autorización de NATS permite limitar qué cliente publica y a qué se suscribe. IT administra usuarios, servicios y secretos; gerencia solo consulta métricas. El backup copia configuración de NATS, streams persistentes, base de datos y definición de workers.
Qué se instala o configura primero
Una implementación chica puede empezar con dos nodos de aplicación y un NATS en contenedor, usando la imagen oficial documentada para Docker. Para producción conviene separar NATS, PostgreSQL y workers. El primer entregable verificable es un circuito factura-tickets: una factura publicada, un ticket creado, un reintento forzado y una métrica visible. El costo operativo base puede ir de USD 30 a USD 90 mensuales, entre ARS 45.000 y ARS 135.000 al dólar oficial de venta de ARS 1.500. Ese rango incluye VPS, almacenamiento pequeño, monitoreo y backup, sin contar horas de desarrollo. El tiempo de implementación razonable es de una a dos semanas si ya existen API internas. UMSA puede ayudar cuando el equipo necesita ordenar integraciones sin cambiar todo el ERP. El trabajo inicial es escribir nombres de subjects, dueños, permisos y regla de reintento. La mejora visible aparece cuando soporte deja de preguntar si el proceso corrió y mira una cola con estado y responsable asignado.
Dónde se rompe y cómo probarlo
El primer riesgo es duplicar acciones. La señal aparece cuando dos tickets nacen de la misma factura. La prueba es publicar dos veces el mismo mensaje con el mismo identificador y verificar que PostgreSQL acepte un solo efecto. El segundo riesgo es abrir permisos demasiado amplios. La señal es un servicio que puede leer > o publicar en subjects de administración. La prueba es conectar un usuario de prueba y confirmar que solo publica y lee los nombres permitidos. El tercer riesgo es creer que persistencia equivale a restauración. La señal aparece cuando el stream existe, pero no se puede reconstruir qué worker consumió cada evento. La prueba es bajar un worker, publicar diez mensajes, levantarlo, procesar la cola y restaurar métricas desde backup en un entorno limpio. Una cola útil deja una pregunta concreta para el lunes: ¿qué mensaje quedó sin procesar y quién lo tiene que mirar?
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.