RabbitMQ, Kafka o SQS: cómo elegir sin arrepentirte

La pregunta llega casi siempre igual: “¿Kafka o RabbitMQ?”. Y casi siempre es la pregunta equivocada, porque ninguno de los dos es mejor: resuelven problemas distintos con modelos distintos.

Lo que sí se puede hacer es ordenar la decisión. En esta guía comparo las tres familias de mensajería —brokers tradicionales, plataformas de streaming y servicios serverless— con los cinco criterios que de verdad deciden: quién consume, si necesitas replay, qué debe ir ordenado, cuánto enrutamiento y cuánta operación puedes sostener.

Si es tu primera vez por aquí, esta es la vista de conjunto: empieza por el criterio que más te duela y salta al artículo que lo desarrolla.

Elegir broker por moda es como alquilar un camión para llevar una carta: arranca, cumple y te deja pagando peaje, seguro y plaza de garaje. La herramienta grande no es un problema hasta que llegan la factura y las guardias.

Tres familias, tres filosofías

1. Brokers de mensajes: RabbitMQ, ActiveMQ, Artemis, IBM MQ

Modelo smart broker, dumb consumer. El broker sabe quién ha recibido qué, aplica enrutamiento avanzado (exchanges, routing keys, cabeceras), gestiona prioridades y entrega a los consumidores. Es el modelo de RabbitMQ.

El mensaje vive hasta que alguien lo confirma. Después desaparece. Es un sistema de reparto de trabajo, no un archivo.

2. Event streaming: Kafka, Pulsar, Redpanda

Modelo dumb broker, smart consumer. El broker guarda un log inmutable en disco, particionado y ordenado. No decide a quién entregar: el consumidor pide y avanza su propio puntero con un offset. Es el modelo de Kafka.

El mensaje no se borra al leerse. Persiste por tiempo o tamaño, y por eso se puede releer. Es un sistema de registro de hechos, no de reparto.

Pulsar añade una capa de almacenamiento separada (BookKeeper) y suscripciones que mezclan ambos mundos. Redpanda implementa la API de Kafka en C++ y elimina la JVM. Son variantes del mismo paradigma, no herramientas distintas.

Infraestructura gestionada, sin clústeres, como SQS y SNS. Colas estándar o FIFO, escalado automático, ventanas de visibilidad y DLQ. El mensaje se borra explícitamente por API tras procesarlo.

Es la opción con menos operación y menos control. Para el 80% de los equipos pequeños, la ecuación sale a favor.

La tabla que resume todo

Característica	RabbitMQ	Kafka	SQS (+ SNS)
Paradigma	colas transaccionales y pub/sub	log distribuido append-only	cola gestionada
Despacho	push (con prefetch)	pull por lotes	pull (corto o largo)
Persistencia	efímera tras ACK	duradera por retención	hasta 14 días
Enrutamiento	muy flexible: direct, topic, fanout, headers	mínimo: partición por clave	ninguno; el fan-out lo da SNS
Orden	por cola, con un consumidor	por partición	FIFO por grupo / best-effort
Throughput	decenas de miles/s por nodo	cientos de miles/s por broker	automático; FIFO limitado
Prioridades	sí	no	no
Replay	no	sí	no
Operación	media	media-alta	nula
Coste	servidor o gestión	clúster o gestión	por petición

La columna que más se ignora es operación, y es la que más caro sale. Un Kafka autogestionado con tres brokers, disco, upgrades y rebalances es un trabajo a tiempo parcial. Un SQS es una línea de código.

Las cinco preguntas que deciden

1. ¿Quién consume?

Un worker que reparte tareas → cola. RabbitMQ o SQS.
Varios equipos que necesitan el mismo flujo, cada uno a su ritmo → log. Kafka.
Varios servicios que necesitan una copia de la notificación → pub/sub. SNS con colas detrás, o fanout de RabbitMQ.

2. ¿Necesitas volver atrás?

Si mañana descubres un bug de cálculo y quieres reprocesar los últimos tres días, la respuesta es Kafka. Ni RabbitMQ ni SQS te lo dan: cuando el mensaje se confirma, se borra.

Ese requisito, por sí solo, descarta dos de las tres opciones.

3. ¿Qué necesita estar ordenado?

Nada: cola estándar.
Por pedido o cuenta: Kafka con la clave correcta, o SQS FIFO con grupos.
Todo el sistema: una sola partición o un solo consumidor. Y prepárate para el techo de throughput.

“Orden global” casi nunca es un requisito real. Casi siempre es “orden por entidad”, que es mucho más barato.

4. ¿Cuánto enrutamiento necesitas?

Enrutar por tipo de evento a colas distintas: exchange topic de RabbitMQ.
Enrutar por atributos: SNS filter policies o EventBridge.
Enrutar por contenido complejo con reglas y esquemas: EventBridge.
Nada: una cola y un worker.

5. ¿Quién se levanta a las tres de la mañana?

Si la respuesta es “nadie, somos dos”, la operación pesa más que cualquier característica. Un broker que no sabes operar es una deuda, no una ventaja.

El árbol de decisión

¿Necesitas releer eventos del pasado o auditar el flujo?
├── Sí ──▶ ¿Necesitas millones de eventos/día y varios consumidores?
│           ├── Sí ──▶ Kafka (o Redpanda / Pulsar)
│           └── No ──▶ Kafka pequeño o Postgres + outbox
└── No ──▶ ¿Necesitas enrutamiento complejo o prioridades?
            ├── Sí ──▶ RabbitMQ
            └── No ──▶ ¿Quieres cero operación?
                        ├── Sí ──▶ SQS (+ SNS si hay fan-out)
                        └── No ──▶ RabbitMQ gestionado o SQS

Si el árbol te lleva a “Postgres + outbox”, no es un fracaso. Es la decisión más sensata para miles de eventos al día: una tabla, un worker y FOR UPDATE SKIP LOCKED. Menos piezas, menos fallos.

El coste real, con números

Hagamos el ejercicio con 10 millones de eventos al mes. Precios públicos de referencia; compruébalos antes de presupuestar.

Opción	Coste aproximado/mes	Notas
SQS estándar	15-25 $	unas 3 peticiones por mensaje
SNS + SQS (fan-out a 3 colas)	30-50 $	publicaciones + peticiones
RabbitMQ gestionado pequeño	30-100 $	según proveedor y HA
RabbitMQ autogestionado	20-40 $ + horas	VPS y tu tiempo
Kafka gestionado (MSK)	400-700 $	mínimo 3 brokers
Kafka autogestionado	150-300 $ + horas	3 VPS, disco, operación

La fila que decide muchas conversaciones no es la del coste de infraestructura: es la de las horas. Un ingeniero a media jornada manteniendo un clúster cuesta mucho más que la diferencia entre SQS y MSK.

Y hay un coste que no se ve: el coste de equivocarse. Migrar de SQS a Kafka seis meses después es más caro que empezar con SQS y subir cuando el requisito de replay aparezca de verdad.

Escenarios concretos

Escenario	Elección razonable	Por qué
Generar facturas en segundo plano	SQS o RabbitMQ	tarea, reintentos, sin replay
Miniaturas de imágenes	SQS	picos enormes, cero operación
Eventos de pedido para 4 servicios	Kafka	varios consumidores, auditoría
Notificar a 5 servicios a la vez	SNS → SQS	fan-out gestionado
Auditoría y reconstrucción de estado	Kafka	retención y replay
Telemetría de miles de dispositivos	Kafka	volumen y retención
Enrutar por tipo de evento	RabbitMQ topic	routing keys
RPC entre servicios	HTTP/gRPC	no es mensajería
Tareas programadas	EventBridge Scheduler	no es una cola

Los anti-patrones que veo una y otra vez

1. Kafka como bus RPC. Montar un topic de peticiones y otro de respuestas para simular llamadas síncronas. Si necesitas una respuesta inmediata, usa HTTP. Kafka no está diseñado para eso y la latencia te lo recuerda.

2. Kafka para 1.000 eventos al día. Tres brokers, un schema registry y un equipo sin experiencia para mover el equivalente a un cron. El coste operativo se come el beneficio.

3. SQS como event store. Borras el mensaje al procesarlo. Si necesitas el histórico, no hay nada que consultar.

4. RabbitMQ para analytics con replay. Un fanout copia, pero no retiene. Cuando necesitas reprocesar, ya no están.

5. Fan-out sin filtros. Todos los suscriptores reciben todo. Multiplicas el coste y el ruido.

6. Asumir exactly-once. Los tres sistemas, en la práctica, entregan al menos una vez. La idempotencia es tu responsabilidad, no una casilla de configuración.

7. Una cola para todo. Mezclar correos, facturas y webhooks en la misma cola hace imposible razonar sobre prioridades, reintentos y DLQ.

8. Sin DLQ ni alarmas. Los mensajes fallidos desaparecen y nadie se entera hasta que un cliente pregunta.

La dimensión que no sale en las tablas: el equipo

Elige la herramienta que tu equipo puede operar, no la que gana en un benchmark.

¿Sabéis diagnosticar un consumer lag que crece?
¿Tenéis un plan para un disco lleno en un broker?
¿Alguien ha hecho un upgrade de Kafka sin downtime?
¿Hay guardias y runbooks?

Si la respuesta es no, el orden correcto es SQS primero, RabbitMQ gestionado si necesitas enrutamiento, y Kafka cuando el requisito de replay y volumen sea real y tengas a alguien que lo sostenga.

La recomendación final

Equipo de 1 a 5 personas, tareas asíncronas y notificaciones: SQS + SNS. Cero operación, coste ridículo.
Enrutamiento complejo, prioridades o protocolos como MQTT/STOMP: RabbitMQ.
Varios consumidores independientes, auditoría, replay, volumen alto: Kafka.
Eventos de negocio en una app pequeña: Postgres + outbox. Sí, en serio.

Y una regla que ahorra muchos disgustos: empieza por la opción más simple que cumpla el requisito de hoy, no el de dentro de tres años. La mensajería se puede cambiar; el tiempo perdido operando algo que no necesitabas, no.

Para seguir leyendo

Las tres piezas comparten una idea: el broker no arregla el diseño. Solo lo hace explícito.