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

> RabbitMQ, Apache Kafka y Apache Pulsar mueven mensajes, pero resuelven problemas muy diferentes. Cuándo elegir cada uno según tu arquitectura y modelo de datos.

- Página canónica: https://www.stellarflavor.com/blog/rabbitmq-kafka-pulsar-mover-datos-2026
- Fecha: 2026-03-02
- Sitio: Stellar Flavor (https://www.stellarflavor.com/)
- Contacto: sun@stellarflavor.com

---

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.