Saltar al contenido principal

🍃 TinyMQ — La Fortaleza Ultraligera

Versión: Checking version... | Licencia: GPL v3 | Lenguaje: Go (stdlib pura)

TinyMQ es un message broker construido desde cero en Go puro, sin dependencias externas, diseñado para desarrolladores que necesitan mensajería asíncrona fiable de nivel empresarial sin la carga operativa de Kafka, RabbitMQ o NATS JetStream.


La Filosofía Cero-Hinchazón

Los message brokers modernos son maravillas de la ingeniería — y representan un exceso brutal para la mayoría de proyectos.

Configurar un runtime de Erlang (RabbitMQ), gestionar JVMs y clusters de Zookeeper (Kafka), o escribir 12 archivos YAML solo para pasar mensajes JSON entre tres microservicios no es una ganancia de productividad — es un impuesto operativo.

TinyMQ se construyó sobre un único principio:

No deberías necesitar un equipo de DevOps para desplegar una cola de mensajes.

Esto se traduce en restricciones técnicas concretas:

RestricciónValor
Dependencias externas0
Tamaño de imagen Docker~13 MB (desde scratch)
CVEs en Docker Scout0
Archivos de configuración necesarios0
Tiempo de configuración< 60 segundos

¿Por Qué No Kafka, RabbitMQ o NATS?

Esto no es una crítica a esas herramientas — es una evaluación honesta sobre cuál encaja mejor.

RabbitMQ

  • Requiere un runtime de Erlang/OTP
  • Configuración de cluster compleja con nodes dedicados
  • Alto consumo de memoria incluso en reposo
  • El protocolo AMQP añade complejidad al cliente

Apache Kafka

  • Requiere una JVM (o un binario nativo de 500 MB+)
  • Diseñado para streaming de logs a escala, no para colas de tareas simples
  • Curva de aprendizaje pronunciada para los operadores

NATS JetStream

  • Aunque es increíblemente rápido, configurar JetStream para persistencia implica gestionar streams, subjects y configuración de consumers, lo que puede resultar excesivamente complejo para casos de uso simples.

TinyMQ

  • Binario Go puro, compila en un único ejecutable estático
  • Sin dependencias de runtime — corre desde Docker scratch
  • Multi-protocolo de serie (HTTP, MQTT, NATS, WS, SSE)
  • Complejidad operativa: docker run -p 7800:7800 ghcr.io/x-name15/tinymq:latest

¿Para Quién Es TinyMQ?

TinyMQ es la herramienta adecuada cuando:

  • ✅ Estás construyendo un homelab, proyecto personal o MVP
  • ✅ Tienes recursos de servidor limitados (un VPS de $4/mes es suficiente)
  • ✅ Quieres un despliegue sin configuración — sin XML, sin YAML, sin DSL
  • ✅ Necesitas persistencia en disco con garantías WAL sin la sobrecarga de Kafka
  • ✅ Estás integrando servicios heterogéneos mediante HTTP, MQTT o NATS
  • ✅ Necesitas patrones empresariales (DLQ, TTL, Broadcast, Webhooks) sin la complejidad empresarial

TinyMQ no es la herramienta adecuada cuando:

  • ❌ Necesitas procesar millones de eventos por segundo (TinyMQ llega a unas pocas decenas de miles por node)
  • ❌ Necesitas logs de topics particionados al estilo Kafka para event sourcing

Matriz de Funcionalidades Core

FuncionalidadDescripción
Persistencia WALArchivos .log de solo adición por topic, con compactación automática al arrancar
Clustering (P2P)Replicación basada en quorum sin master, sin ZooKeeper ni librerías Raft
Gateway Multi-ProtocoloHTTP REST nativo, MQTT v3.1.1, NATS, WebSockets y SSE
Dead Letter QueuesAislamiento automático de mensajes problemáticos tras 3 reintentos
Enrutamiento TemporalSoporte nativo de ?delay=10s y ?ttl=5m
Push ConsumersEntrega fire-and-forget basada en Webhooks (con firma HMAC)
Consumer GroupsVinculación virtual de topics para patrones Pub/Sub
Priority QueuesEncolar con prioridades Alta/Normal/Baja
IdempotenciaEvita el procesamiento duplicado mediante Idempotency-Key o SHA256 del payload
Broadcast y BatchingFan-out a todos los consumers en espera, o extracción de N mensajes a la vez
Soporte Nativo K8sResolución de identidad integrada para StatefulSets
Protección OOMLímite de payload de 2 MB + contrapresión de 100k mensajes en RAM + Rate Limiting

Visión General de la Arquitectura

TinyMQ enruta mensajes de forma transparente a través de 5 transportes nativos, unificados por un Write-Ahead Log central.


Próximos Pasos