Kafka vs. RabbitMQ vs. SQS: ¿cómo eliges realmente para un caso de uso dado?
Tres sistemas de mensajería probados en producción resuelven problemas parecidos pero distintos: elegir mal significa pelear contra la herramienta durante años.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Kafka vs. RabbitMQ vs. SQS: ¿cómo eliges realmente para un caso de uso dado?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Por qué esta pregunta separa a los candidatos
Cualquiera puede nombrar tres brokers de mensajería. Lo que distingue a una respuesta senior es reconocer que Kafka, RabbitMQ y SQS no son implementaciones intercambiables de "una cola" — codifican tres modelos mentales distintos de qué es un mensaje y cuánto tiempo debería vivir. Si entiendes bien el modelo mental, la pregunta de "cuál elijo" prácticamente se responde sola.
#Qué es realmente cada uno
Kafka es un log de commits distribuido, particionado y replicado. Los productores agregan eventos a las particiones de un topic; el broker no lleva registro de qué consumidor "procesó" qué. En cambio, cada grupo de consumidores lleva su propio offset dentro de cada partición. Los eventos se retienen durante una ventana configurada (o indefinidamente, o compactados hasta el último valor por clave) sin importar si alguien ya los leyó. Esto es lo que convierte a Kafka en un sistema de replay: un nuevo grupo de consumidores puede conectarse hoy y leer todo el historial de un topic desde el offset cero.
RabbitMQ es un broker de mensajería construido sobre el modelo AMQP: los productores publican en un exchange, y los bindings enrutan cada mensaje a cero o más colas según una routing key (exchange directo, de topic, fanout o de headers). Un mensaje se elimina de una cola una vez que un consumidor lo confirma (ack). RabbitMQ no retiene historial para replay — una vez consumido y confirmado, el mensaje desaparece. Lo que te da a cambio es enrutamiento expresivo, prioridades por mensaje, mensajes retrasados/con TTL y dead-lettering, todo como funcionalidades de primera clase del broker.
SQS es la cola distribuida totalmente administrada de AWS. Una cola estándar ofrece entrega al menos una vez con orden de mejor esfuerzo y throughput casi ilimitado; una cola FIFO ofrece orden estricto por grupo de mensajes y procesamiento efectivamente exactamente-una-vez (mediante una ventana de deduplicación de 5 minutos) a un techo de throughput menor (hasta ~3.000 mensajes/seg con batching). SQS no tiene concepto propio de exchange — el fan-out a múltiples colas se hace combinándolo con SNS (topic de SNS → múltiples colas de SQS suscritas).
#La distinción central: log vs. broker
Esta única distinción explica casi todas las diferencias posteriores: retención, replay, garantías de orden y cómo escalas a los consumidores.
#Tabla comparativa
| Dimensión | Kafka | RabbitMQ | SQS (Estándar / FIFO) |
|---|---|---|---|
| Modelo | Log de commits distribuido | Broker inteligente, enrutamiento AMQP | Cola distribuida administrada |
| Orden | Por partición, estricto | Por cola, FIFO por defecto | Ninguno (Estándar) / por grupo (FIFO) |
| Garantía de entrega | Al menos una vez (exactamente una vez con transacciones) | Al menos una vez (o como máximo una vez sin acks) | Al menos una vez (Estándar); efectivamente exactamente una vez dentro de la ventana de dedup (FIFO) |
| Retención / replay | Ventana configurable o indefinida; replay completo | Desaparece al confirmarse; sin replay | Desaparece al eliminarse; sin replay |
| Techo de throughput | Muy alto (millones/seg entre particiones) | Alto, pero menor que Kafka; el enrutamiento agrega costo de CPU | Estándar: casi ilimitado; FIFO: ~3.000 msg/s con batching |
| Complejidad de enrutamiento | Mínima (solo topic/partición); fan-out vía grupos de consumidores | Rica (exchanges directos/topic/fanout/headers) | Ninguna nativa; requiere SNS para fan-out |
| Modelo de consumo | Pull, grupos de consumidores, cada uno con su propio offset | Push o pull, el broker lleva el estado de ack | Pull (long polling), el broker lleva el visibility timeout |
| Carga operativa | La más alta — ZooKeeper/KRaft, particiones, rebalanceo | Media — clustering, colas espejadas/de quorum | La más baja — totalmente administrado, sin servidores |
| Mejor uso | Streaming de eventos, event sourcing, agregación de logs, replay multi-consumidor | Colas de tareas, flujos estilo RPC, enrutamiento complejo, prioridad/retraso | Desacoplamiento simple, triggers serverless, operación mínima |
#Cómo elegir según el caso de uso
Streaming de alto throughput / event sourcing / pipelines de analítica → Kafka. Si varios equipos independientes necesitan consumir el mismo stream de eventos a ritmos distintos (detección de fraude en tiempo real, un data warehouse que carga cada hora, un equipo nuevo de analítica haciendo backfill desde el día uno), el modelo de log-y-replay de Kafka es el único de los tres diseñado para eso. También es la elección correcta cuando el orden dentro de una clave importa a gran escala —por ejemplo, todos los eventos de un mismo ID de usuario deben procesarse en orden— porque Kafka particiona por clave y garantiza el orden dentro de una partición.
Colas de tareas / enrutamiento complejo / patrones tipo RPC → RabbitMQ. Si necesitas una cola de trabajo clásica (muchos workers compitiendo por tareas), colas de prioridad, reintentos retrasados con TTL por mensaje, o enrutar un mensaje a colas distintas según su contenido (exchange de topic con bindings con wildcards), el enrutamiento del lado del broker de RabbitMQ hace esto de forma nativa sin infraestructura adicional. También brilla en request/reply (RPC sobre mensajería) usando una cola de reply-to e IDs de correlación.
Desacoplamiento simple con operación mínima → SQS. Si solo necesitas desacoplar dos servicios nativos de AWS —una Lambda que necesita reintentar de forma segura, una subida a S3 que debe disparar procesamiento asíncrono, una cola de trabajos en segundo plano para un equipo pequeño sin personal dedicado de infraestructura—, SQS te da entrega durable sin servidores que administrar. Usa colas Estándar salvo que tengas un requisito específico y acotado de orden estricto o semántica exactamente-una-vez, porque el techo de throughput y la latencia adicional de FIFO tienen un costo real.
#Un ejemplo de enrutamiento
El siguiente diagrama muestra por qué el exchange de topic de RabbitMQ es una herramienta distinta al particionado de Kafka: un mismo mensaje puede enrutarse a varias colas según el patrón de la routing key, y cada cola sirve a un consumidor completamente distinto.
#Qué escuchan los entrevistadores
Una buena respuesta no solo recita la tabla — explica la consecuencia del modelo subyacente: que el replay de Kafka cambia cómo piensas el reprocesamiento después de un bug (reproducir desde un offset anterior en lugar de reprocesar una dead-letter queue), que la entrega basada en ack de RabbitMQ significa que un mensaje no confirmado se reentrega y tu consumidor debe ser idempotente, y que el visibility timeout de SQS es efectivamente un préstamo que hay que extender en trabajos largos o el mensaje reaparece y se procesa dos veces.
🧠 Check your understanding
0/3 · 0/3 answered1. Un equipo necesita que tres servicios independientes —detección de fraude (tiempo real), un data warehouse (carga por lotes cada hora) y un equipo nuevo de analítica haciendo backfill desde el día uno— consuman cada uno el historial completo del mismo stream de eventos a su propio ritmo. ¿El modelo de qué sistema encaja de forma nativa?
2. ¿Por qué una cola Estándar de SQS encaja mal en un flujo que requiere orden estricto por clave a alto volumen?
3. ¿Qué costo operativo asume un equipo al elegir Kafka para una integración de bajo volumen entre dos servicios que no necesitan replay ni alto throughput?