¿RabbitMQ o Kafka? Es la pregunta equivocada.
Cada vez que alguien pregunta «¿RabbitMQ o Kafka?», la pregunta ya viene mal planteada. No son dos opciones que compitan por el mismo trabajo —son dos herramientas que resuelven problemas distintos, y comparar sus caracterÃsticas en una tabla no aclara mucho si antes no se entiende qué tipo de problema se está resolviendo.
Dos modelos completamente distintos
La diferencia central no está en el rendimiento ni en la cantidad de protocolos que soportan. Está en una pregunta simple: ¿qué pasa con un mensaje después de que alguien lo lee?
RabbitMQ es una cola tradicional. Un mensaje entra, un consumer lo toma, lo procesa, lo confirma, y desaparece. Implementa AMQP, un protocolo de mensajerÃa con exchanges (direct, topic, fanout) que permite rutear un mensaje hacia distintas colas según reglas especÃficas. Es la herramienta adecuada cuando algo debe ejecutarse una sola vez: procesar un pago, enviar un correo, generar un PDF.
Kafka es otra cosa: un log distribuido. Los eventos se organizan en topics, cada topic se divide en particiones, y cada evento nuevo se agrega al final de esa partición —nunca se edita ni se borra de forma individual. Es append-only. Lo que distingue a Kafka es que un evento no desaparece cuando alguien lo lee. Queda persistido según una polÃtica de retención (7 dÃas, 30 dÃas, o de forma indefinida), y cada consumer mantiene su propio puntero (offset) sobre ese log —puede empezar desde el principio, continuar donde se quedó, o releer todo desde cero meses después.
text
RabbitMQ: Productor → Cola → Consumer lee → mensaje se borra
Kafka: Productor → Log (partición) → Consumer A lee (offset propio)
→ Consumer B lee (offset propio)
→ el evento permanece
El criterio real para decidir
La decisión no deberÃa basarse en comparar throughput o interfaces de administración. La pregunta que realmente importa es:
¿El mensaje debe desaparecer una vez procesado, con lógica de ruteo hacia un destino especÃfico? → RabbitMQ. ¿El evento debe quedar como historial, ser leÃdo por múltiples consumers independientes sin que se acoplen entre sÃ, o manejar volúmenes masivos? → Kafka.
Esto no es una cuestión de tamaño de empresa. Una startup con necesidad de streaming de eventos en tiempo real puede requerir Kafka desde el primer dÃa. Una gran corporación que solo necesita procesar tareas en segundo plano puede resolverlo perfectamente con RabbitMQ, o incluso con algo más simple. El tamaño de la empresa no determina la herramienta correcta —el patrón de datos y comunicación sà lo hace.
Casos reales
Uber: un evento, múltiples consumers desacoplados
Cada viaje genera un flujo constante de eventos: ubicación del conductor, cambios de estado (solicitado → aceptado → en curso → completado), cálculo de precio dinámico. Ese flujo de eventos es leÃdo en paralelo por decenas de servicios independientes: el que calcula el tiempo estimado de llegada, el que actualiza el mapa del pasajero, el que factura, el que detecta fraude. Ninguno bloquea a los demás. Si el servicio de detección de fraude procesa con demora, el mapa del pasajero se sigue actualizando en tiempo real sin ningún problema —porque cada consumer avanza sobre el mismo log a su propio ritmo.
Detección de fraude bancario: por qué es necesario que persista
Cada transacción con tarjeta se publica como evento. Un servicio de fraude la analiza en milisegundos sin bloquear la transacción real. Pero no termina ahÃ: ese mismo evento también lo consume el sistema de puntos y recompensas, el de analytics, y potencialmente un equipo de datos que meses después decide reentrenar un modelo de detección con todo el histórico del último trimestre. Esa última parte —leer eventos de hace meses como si fuera la primera vez— es exactamente lo que RabbitMQ no puede ofrecer: ahà el mensaje ya se eliminó en cuanto el primer consumer lo confirmó.
Aplicado a un proyecto real
Cuando una tarea debe ejecutarse una sola vez y termina ahà —enviar un correo de bienvenida, procesar una imagen subida, generar un reporte— RabbitMQ (o incluso algo más liviano como BullMQ sobre Redis, en el ecosistema Node) resuelve el problema sin complejidad innecesaria.
Cuando varios servicios necesitan enterarse del mismo evento de forma independiente, cuando el volumen es alto, o cuando en algún momento será necesario reconstruir estado histórico a partir de eventos pasados, Kafka deja de ser una opción reservada para «empresas grandes» y pasa a ser la herramienta correcta para ese tipo de problema.
La pregunta correcta nunca es «cuál es mejor». Es: cuando alguien lee este mensaje, ¿debe desaparecer, o debe permanecer disponible para que otros lo lean también, incluso mucho después?
