RabbitMQ para colas de mensajes: cuándo sigue siendo la opción

Actualizado: 2026-05-03

En la última década, Kafka^[1] se ha convertido en sinónimo de “mensajería moderna” en muchas conferencias. Pero en el día a día de equipos de ingeniería, RabbitMQ^[2] sigue siendo la herramienta correcta para muchos casos. Las dos hacen cosas parecidas desde fuera; por dentro resuelven problemas muy distintos.

Puntos clave

• RabbitMQ es un message broker tradicional: colas, routing flexible, acknowledgments por mensaje.
• Kafka es un log distribuido: retención larga, throughput masivo, replay de eventos.
• Task queues con reintentos, RPC asíncrono y pub/sub con enrutamiento complejo son el territorio natural de RabbitMQ.
• NATS es la tercera vía para latencia extrema y footprint mínimo.
• Tres errores de producción recurrentes: colas sin límite, sin dead-letter queue y prefetch mal dimensionado.

Diferencias fundamentales

RabbitMQ es un message broker tradicional. Está diseñado alrededor de colas con enrutamiento flexible (exchanges, bindings, routing keys), acknowledgments por mensaje, y el supuesto de que los consumidores procesan y eliminan.

Kafka es un log distribuido. Mensajes persisten en particiones ordenadas con offset, los consumidores navegan por ese log independientemente, y el sistema está optimizado para throughput masivo con retención configurable.

La diferencia se nota en qué problemas modela bien cada uno:

• Task queue con reintentos finitos → RabbitMQ. Rechaza un mensaje y se re-entrega automáticamente; descarta tras N fallos a dead-letter queue.
• Event sourcing con replay → Kafka. Mantiene el log días y cualquier consumidor nuevo puede leer desde el principio.
• RPC asíncrono con correlación → RabbitMQ. La cola de respuestas con reply_to y correlation_id es un patrón canónico.
• Streaming analytics sobre eventos → Kafka. Kafka Streams o Flink sobre Kafka resuelven esto nativamente.

Patrones clásicos de RabbitMQ

Tres patrones que se implementan limpiamente con RabbitMQ:

Work queue (round-robin)

Una cola única, múltiples consumidores. RabbitMQ reparte mensajes de forma equilibrada. Ideal para procesar imágenes, enviar emails, generar reportes — trabajos independientes donde cualquier worker puede atender cualquier mensaje.

Producer → [queue: emails] → Consumer-1
                          → Consumer-2
                          → Consumer-3

Publish/subscribe con fanout

Un exchange fanout replica cada mensaje a todas las colas enlazadas. Útil para notificar eventos a múltiples servicios independientes.

Producer → [exchange: user-events (fanout)] → queue-audit  → Audit service
                                            → queue-email  → Email service
                                            → queue-mobile → Mobile push service

Topic routing

Un exchange topic filtra por patrones en la routing key. Permite a consumidores subscribirse a subconjuntos específicos.

Producer → [exchange: orders (topic)] → [queue: orders.premium.#]   → Premium handler
                                     → [queue: orders.*.europe]     → EU handler
                                     → [queue: orders.*.us]         → US handler

Ninguno de estos patrones es imposible con Kafka, pero RabbitMQ los expresa directamente con su modelo. En Kafka requieren construcciones sobre particiones y consumer groups.

Cuándo Kafka es mejor

Hay casos donde Kafka supera a RabbitMQ:

• Throughput muy alto. Por encima de ~50k mensajes/segundo sostenidos, Kafka escala mejor horizontalmente.
• Retención larga del log. Si necesitas que los eventos persistan días o semanas para re-procesamiento, Kafka está diseñado para eso.
• Orden estricto por clave. Con particionamiento por clave, Kafka garantiza orden total dentro de la partición.
• Integración con ecosistema de streaming. Kafka Connect, ksqlDB, Kafka Streams, Flink, Spark Streaming — el ecosistema es rico.

Y NATS como tercera vía

NATS^[3] a veces es la mejor opción cuando:

• La latencia importa más que la persistencia (trading, IoT de baja latencia).
• Quieres un broker ligero con footprint mínimo.
• JetStream (el modo con persistencia) cubre los casos simples donde RabbitMQ sería overkill.

No es reemplazo de Kafka en streaming pesado, pero para pub/sub y request/reply compite con RabbitMQ en simplicidad operativa.

Errores comunes en producción

De incidentes vistos con RabbitMQ, tres patrones recurrentes:

1. Colas sin límite. Sin max-length o x-message-ttl, una cola a la que nadie consume puede crecer hasta llenar el disco. Establece límites explícitos.
2. Sin dead-letter queue. Mensajes que fallan repetidamente entran en bucle infinito o se pierden silenciosamente. Configura DLX + DLQ y monitoriza la DLQ.
3. Prefetch desorbitado. prefetch_count: 1000 con consumidores lentos hace que un consumidor acapare toda la cola. Típicamente 1–10 para trabajos largos, 50–200 para trabajos cortos.

Observabilidad

Cualquiera que sea el broker, monitoriza estas métricas:

• Queue depth. Crecimiento sostenido es señal de que los consumidores no siguen el ritmo.
• Consumer utilization. Tiempo ocupado / tiempo total; valores bajos indican bottleneck en I/O o lógica.
• Redelivery rate. Mensajes re-entregados indica fallos parciales o timeouts mal dimensionados.
• Connection churn. Reconexiones frecuentes agotan recursos del broker.

Prometheus exporters^[4] para RabbitMQ exponen todas estas métricas. Un buen diseño de alertas sobre ellas sigue los mismos principios que aplica la gestión de observabilidad en Kubernetes: priori lo que tenga impacto en el usuario, silencia el ruido restante. Para la capa de mensajería que conecta microservicios, véase también contract testing con Pact como herramienta complementaria de verificación de la interfaz.

Conclusión

RabbitMQ sigue siendo la mejor elección para un amplio rango de casos: task queues, pub/sub con enrutamiento complejo, RPC asíncrono. Kafka gana cuando el problema es inherentemente de streaming o cuando la escala supera el umbral. Elegir por el caso concreto, no por la moda, es lo que diferencia arquitecturas mantenibles de las que se vuelven pesadilla operativa.

1. Kafka
2. RabbitMQ
3. NATS
4. Prometheus exporters