Broker de mensajes gestionado. Tus eventos, garantizados.
Un servicio de cola de mensajes que desacopla productores de consumidores. Publicás eventos, nosotros los entregamos — con garantías de delivery, TLS end-to-end y cero ops de tu lado.
messageQueue es un servicio de cola de mensajes gestionado. En lugar de instalar y operar tu propio broker —RabbitMQ, Kafka, Redis Streams— te conectás al nuestro y publicás eventos. Nosotros nos ocupamos de la disponibilidad, el escalado y la entrega.
La idea es simple: un productor publica un mensaje en un tópico, el mensaje persiste en la queue, y un consumidor lo lee cuando está disponible. Si el consumidor falla, el mensaje espera. Si tarda, el mensaje espera. Nada se pierde.
Podés tener múltiples productores publicando al mismo tópico y múltiples consumidores procesando en paralelo — cada uno a su propio ritmo, sin coordinación entre ellos.
Si es tu primer message broker, estos son los cuatro conceptos que necesitás entender. Si ya sabés, reconocerás el patrón.
Cualquier sistema que genera un evento y lo envía a la queue. En nuestro ecosistema el productor más común es el T-PoS — cada lectura NFC genera un evento. Pero cualquier servicio tuyo puede ser productor: una app, un webhook, un cron.
El canal entre productor y consumidor. Los mensajes se almacenan en la queue hasta que un consumidor los procesa y confirma. Si el consumidor está caído, los mensajes esperan. Nada se descarta sin un ack explícito de tu lado.
Tu servicio que lee mensajes de la queue y ejecuta la lógica de negocio. Puede estar escrito en Node, Python, PHP, Go — lo que ya usás. Lee el evento, aplica tu lógica, devuelve una respuesta y envía el ack. Si falla, el mensaje vuelve a la queue.
Una categoría de mensajes dentro de messageQueue. tag.scanned, payment.confirmed, session.started. Cada tópico es una queue independiente. Un consumidor puede suscribirse a uno o varios tópicos según su lógica de negocio.
Del evento físico a tu sistema en milisegundos. messageQueue es la infraestructura que conecta los dos extremos.
El productor genera un evento — un TAG leído, un pago procesado, una sesión iniciada — y lo publica en el tópico correspondiente de messageQueue.
messageQueue recibe el mensaje y lo persiste. Queda disponible para el consumidor dentro del visibility timeout configurado. Nada se pierde en tránsito.
Tu consumidor lee el mensaje, ejecuta su lógica y envía el ack. Si falla o supera el timeout, el mensaje vuelve a la queue para reintento automático.
Tu consumidor puede devolver una respuesta al productor — luz verde, luz roja, texto. El T-PoS la muestra al operador en tiempo real, cerrando el ciclo.
Las propiedades que permiten usar messageQueue como capa crítica de tu arquitectura, sin miedo a perder eventos.
Cada mensaje se entrega al menos una vez. Sin ack dentro del visibility timeout, vuelve a la queue. Diseñá tu consumidor idempotente — es la única precaución necesaria de tu lado.
Todo el tráfico entre productor, messageQueue y consumidor viaja cifrado. No hay mensajes en texto plano en ningún punto del circuito.
Los mensajes no viven en memoria volátil. Se persisten en almacenamiento duradero y sobreviven reinicios del broker sin perder ningún evento pendiente.
Si el consumidor no procesa un mensaje dentro del visibility timeout, el broker lo vuelve a encolar. Sin ninguna configuración extra de tu parte.
Múltiples dispositivos T-PoS publican en el mismo tópico sin coordinación entre ellos. Escalarás consumidores horizontalmente si el volumen lo demanda.
Controlás cuánto tiempo tiene tu consumidor para procesar un mensaje antes de que vuelva a estar disponible. Configurable por tópico según tus SLAs.
Dos productos construidos sobre messageQueue, disponibles como solución completa si no querés integrar tu propio sistema.
El dispositivo lector NFC que publica en messageQueue cada vez que detecta un TAG. Produce, no procesa. Toda la lógica de negocio queda del lado de tu consumidor.
Ver T-PoS →El software de membresías y cobros recurrentes que consume eventos de messageQueue para registrar dispendios, validar planes y gestionar estados de suscriptores.
Ver Fidelizza →Si ya tenés un sistema y querés agregar un evento físico como fuente de input, messageQueue puede ser la pieza que falta. Contanos qué tenés y vemos si encaja.
Agendar una charla técnica