Queen MQ presenta un broker de mensajes ACID con colas por entidad y fuerte consistencia

El usuario de GitHub queen-mq ha lanzado Queen, un broker de mensajes de código abierto diseñado para ofrecer garantías ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) en mensajería distribuida. Publicado el 10 de noviembre de 2026, este sistema basado en Rust busca simplificar la arquitectura backend tratando a cada cliente, pedido o conversación como su propia cola, asegurando que los cambios de estado y los acuses de recibo de mensajes se confirmen juntos como una única transacción.

Qué ocurrió

El lanzamiento introduce un broker que se aleja de los modelos tradicionales de consistencia eventual, comunes en sistemas de alto rendimiento. En lugar de depender de mecanismos separados para bloquear, programar o reintentar mensajes fallidos, Queen integra estas capacidades directamente en su núcleo transaccional. La documentación del proyecto destaca que cada paso en un flujo de trabajo, incluyendo el acuse de recibo, el despacho del siguiente mensaje, las actualizaciones de estado y la configuración de temporizadores, se confirma como una unidad atómica. Este enfoque elimina la complejidad de gestionar bloqueos de Redis, tareas cron o tablas de reintentos dedicadas.

Queen admite múltiples lenguajes de programación, incluidos JavaScript, Python, Go y Rust, y ofrece funciones como el procesamiento de streams con ventanas fijas (tumbling), deslizantes (sliding) y de sesión. También incluye soporte para grupos de consumidores confluentes, que solo entregan el mensaje más reciente para particiones donde únicamente importa el último valor. Para patrones de solicitud-respuesta, el broker proporciona colas efímeras en memoria que son rápidas pero se pierden intencionadamente durante fallos, distinguiéndolas de los logs persistentes. El sistema está diseñado para manejar una gestión de estado compleja, ofreciendo almacenamiento clave-valor, bloqueos distribuidos y temporizadores programados dentro del mismo límite transaccional que el procesamiento de mensajes.

Detalles clave

• Transacciones ACID: Cada operación de mensaje, incluyendo acuses, cambios de estado y temporizadores, se confirma atómicamente, garantizando que no ocurran actualizaciones parciales.
• Benchmarks de alto rendimiento: En tres nodos GCP con NVMe local, Queen alcanzó 3 millones de mensajes por segundo con una latencia p99 de 15-25 ms en hasta 10 millones de particiones.
• Recuperación rápida: Un nodo que se reincorpora a un clúster tras cinco minutos de inactividad sincronizó solo un delta de 1,1 GB en 28 segundos, significativamente más rápido que versiones anteriores.
• Agnóstico al lenguaje: Admite clientes en JavaScript, Python, Go y Rust, y permite que productores y consumidores de Kafka sin cambios se conecten mediante un puerto compatible con Kafka.
• Almacenamiento integrado: El broker puede escribir directamente colas en tablas de PostgreSQL o buckets S3 en formatos JSONL o Parquet sin requerir procesos externos.
• Fiabilidad probada: El software superó 226 pruebas Jepsen en la versión 2.7, confirmando que no se perdieron mensajes acusados y que no se mantuvieron leases duplicados.

Contexto

Los brokers de mensajes son componentes esenciales en la arquitectura de software moderna, actuando como intermediarios que permiten a diferentes partes de un sistema comunicarse de forma asíncrona. Los brokers tradicionales como Kafka o RabbitMQ suelen priorizar el rendimiento y la disponibilidad, a veces a costa de la consistencia inmediata. Los desarrolladores frecuentemente deben construir infraestructura adicional, como colas de reintentos respaldadas por bases de datos o gestores de bloqueos distribuidos, para asegurar que la lógica de negocio permanezca consistente cuando los mensajes fallan o llegan fuera de orden.

Las propiedades ACID, típicamente asociadas con bases de datos relacionales, aseguran que las transacciones se procesen de manera fiable. La atomicidad significa que todas las partes de una transacción tienen éxito o fracasan juntas. La consistencia garantiza que la base de datos permanezca en un estado válido. El aislamiento previene que transacciones concurrentes interfieran entre sí, y la durabilidad asegura que los datos confirmados sobrevivan a fallos del sistema. Al llevar estas garantías al brokering de mensajes, Queen intenta reducir la carga operativa para los equipos de ingeniería que previamente tenían que unir múltiples herramientas para lograr una fiabilidad similar.

Por qué importa

Para equipos que ejecutan su propio software, la promesa de cumplimiento ACID en un broker de mensajes puede reducir significativamente la complejidad arquitectónica. Actualmente, muchas aplicaciones autoalojadas requieren una combinación de una cola de mensajes, una base de datos relacional para el estado y un almacén separado para bloqueos distribuidos. Gestionar la consistencia entre estos tres sistemas es una fuente común de errores y sobrecarga operativa. Si Queen cumple sus afirmaciones, los desarrolladores podrían reemplazar esta tríada con un único componente, simplificando el despliegue, la monitorización y la depuración.

Los benchmarks de rendimiento sugieren que esta simplicidad no tiene un coste severo en el rendimiento. Manejar 3 millones de mensajes por segundo con baja latencia es competitivo con jugadores establecidos como Redpanda y Pulsar, particularmente con altos conteos de particiones. Para empresas medianas escalando su infraestructura, la capacidad de drenar 100 GB de lag en 32 segundos y recuperar nodos rápidamente puede marcar la diferencia entre un pequeño contratiempo y una prolongada interrupción durante picos de tráfico.

Sin embargo, adoptar un nuevo componente de infraestructura central conlleva riesgos. Aunque las pruebas Jepsen brindan confianza en su modelo de consistencia, los casos de uso reales en producción varían ampliamente. Los equipos deben evaluar si las características específicas, como las colas por entidad y el volcado integrado a S3, se alinean con sus necesidades de retención y procesamiento de datos. La licencia Apache-2.0 permite el uso comercial y la modificación, lo cual es atractivo para empresas que desean evitar el vendor lock-in mientras mantienen control sobre su código fuente.

Qué puedes hacer

• Revisa la documentación: Descarga el PDF "The little book of QueenMQ" para entender la arquitectura, el modelo de almacenamiento y las garantías de API antes de considerar su adopción.
• Ejecuta pruebas de benchmark: Repite los benchmarks proporcionados usando tu propio hardware o entorno cloud para verificar si el rendimiento y la latencia declarados cumplen con los requisitos de tu aplicación.
• Evalúa rutas de migración: Si actualmente usas Kafka, prueba el puerto compatible con Kafka para ver si los productores y consumidores existentes pueden conectarse sin cambios en el código.
• Analiza necesidades de gestión de estado: Determina si la lógica de tu aplicación se beneficiaría de tener almacenamiento KV, bloqueos y temporizadores integrados directamente en el flujo transaccional de mensajes.
• Prueba escenarios de fallo: Usa la función de clúster en espera y los mecanismos de recuperación de nodos en un entorno de staging para validar el tiempo de reincorporación de 28 segundos y la integridad de los datos.
• Comprueba el soporte de lenguajes: Asegúrate de que las librerías cliente para tus principales lenguajes de desarrollo (JS, Python, Go, Rust) sean suficientemente maduras para tus estándares de producción.