RabbitMQ vs Kafka vs Pulsar: tres formas muy distintas de mover datos

RabbitMQ, Apache Kafka y Apache Pulsar mueven mensajes. Pero bajo esa aparente similitud, resuelven problemas muy diferentes en sistemas distribuidos.

A simple vista, todos permiten que productores envíen datos y consumidores los procesen. Sin embargo, el modelo mental que hay detrás de cada uno cambia completamente cómo diseñas tu arquitectura.

---

RabbitMQ: el broker clásico orientado a tareas

RabbitMQ representa el modelo tradicional de message broker.

• Los productores publican mensajes en exchanges.
• Los exchanges enrutan los mensajes hacia colas.
• Los consumidores compiten por procesar esos mensajes.

El flujo es claro: el mensaje se envía → se procesa → se confirma (ack) → desaparece.

Es un sistema pensado para casos donde importa el “haz esto una vez”:

• Distribución de tareas
• Procesamiento asíncrono
• Workflows empresariales
• Sistemas tipo request/response desacoplados

RabbitMQ es ideal cuando quieres garantizar que cada mensaje se procese una sola vez y no necesitas mantener un histórico largo de eventos.

---

Kafka: no es una cola, es un log distribuido

Kafka cambia completamente el paradigma. No funciona como una cola tradicional, sino como un log distribuido e inmutable.

• Los productores añaden eventos a particiones.
• Los datos permanecen allí según una política de retención (tiempo o tamaño), no según si han sido consumidos.
• Los consumidores leen mediante offsets y pueden volver atrás y reprocesar eventos.

Esto permite algo muy potente: reprocesar datos históricos, alimentar múltiples sistemas con el mismo flujo y crear pipelines de datos y arquitecturas event-driven.

Por eso Kafka es tan fuerte en:

• Event streaming
• Analítica en tiempo real
• Arquitecturas basadas en eventos
• Integración entre múltiples equipos o servicios

En Kafka, los datos no “desaparecen” cuando alguien los lee. Permanecen y pueden ser consumidos múltiples veces.

---

Pulsar: separación entre cómputo y almacenamiento

Pulsar intenta combinar lo mejor de ambos mundos. Su arquitectura separa:

• Brokers → gestionan el tráfico y sirven mensajes
• BookKeeper → almacena los datos en un ledger duradero

En lugar de offsets, los consumidores usan cursors para seguir su posición.

Esta separación permite:

• Escalar almacenamiento y cómputo de forma independiente
• Soportar patrones tipo streaming
• Soportar patrones más cercanos a colas tradicionales

Pulsar ofrece una arquitectura más flexible, especialmente interesante cuando necesitas:

• Multi-tenancy fuerte
• Escalabilidad horizontal muy granular
• Mezclar patrones de cola y streaming en el mismo sistema

---

La pregunta correcta no es “cuál es más rápido”

Elegir entre RabbitMQ, Kafka o Pulsar no debería basarse en popularidad o benchmarks aislados. La decisión real depende de:

• ¿Cómo quieres que fluya la información?
• ¿Cuánto tiempo deben vivir los datos?
• ¿Cuántas veces necesitan ser leídos?
• ¿Qué modelo mental encaja mejor con tu arquitectura?

Necesidad	Herramienta
Procesamiento de tareas puntual y claro	RabbitMQ
Historial reproducible de eventos	Kafka
Arquitectura híbrida y escalable con separación fuerte de almacenamiento y cómputo	Pulsar

En sistemas distribuidos, no estás eligiendo solo una herramienta. Estás eligiendo una forma de pensar los datos.