--- title: 'Comparativa de colas de mensajería: Redis, RabbitMQ, Kafka | DevSense' description: 'Cómo elegir un agente (broker) para el trabajo asíncrono: comparación de colas en memoria (Redis), agentes AMQP (RabbitMQ) y registros de confirmación (Kafka) según la ordenación, escala, durabilidad y costo operativo.' faq: - { question: '¿Cuál es la diferencia principal entre una cola de mensajes (como RabbitMQ) y un agente basado en logs (como Kafka)?', answer: "RabbitMQ utiliza un modelo de 'agente inteligente, consumidor simple' (smart broker, dumb consumer), donde el agente realiza el seguimiento del estado de los mensajes (confirmaciones, lecturas, eliminaciones) y los elimina inmediatamente después de que se consumen correctamente. Kafka utiliza un modelo de 'agente simple, consumidor inteligente' (dumb broker, smart consumer), donde los mensajes se añaden a un registro de escritura anticipada (write-ahead log) en el disco y se conservan durante un período de retención definido. Los consumidores realizan el seguimiento de su propia posición de lectura (offset), lo que les permite reproducir los mensajes de forma independiente." } - { question: '¿Por qué se prefieren las colas de mensajes sobre las tablas de bases de datos para las colas de tareas asíncronas?', answer: 'Las bases de datos no están diseñadas para patrones de cola. El sondeo (polling) de tablas crea contención de bloqueos, alto uso de CPU y fragmentación de tablas (bloat) debido a las rápidas inserciones y eliminaciones. Las colas de mensajes almacenan el estado de la cola en la memoria (o en segmentos de disco secuenciales estructurados) y admiten alertas a consumidores basadas en inserciones directas (push), lo que proporciona un rendimiento mucho mayor y una menor latencia de ejecución.' } - { question: '¿Cómo logra Kafka un alto rendimiento en comparación con los agentes tradicionales?', answer: 'Kafka escribe los mensajes de forma secuencial en un registro de disco (aprovechando la caché de páginas del sistema operativo y la transferencia de copia cero (zero-copy) a los sockets de red), evitando la sobrecarga de serialización en memoria. Particiona los registros para paralelizar las cargas de trabajo de lectura/escritura en múltiples agentes y agrupa los mensajes por lotes para reducir la sobrecarga de red y E/S.' } - { question: '¿Cuándo es Redis una buena opción para mensajería y cuáles son sus límites?', answer: 'Redis es una opción excelente y de baja latencia para colas simples (usando Listas o Pub/Sub) o flujos estructurados (Streams) cuando ya lo utilizas para el almacenamiento en caché. Sin embargo, está limitado por el tamaño de la memoria RAM del servidor, ya que todos los datos activos se almacenan en la memoria, y carece de funciones de enrutamiento avanzadas como el enrutamiento de intercambio (exchanges), reenvío de mensajes fallidos (dead-lettering) o durabilidad garantizada del disco a largo plazo.' } published: '2026-05-31' --- # Comparativa de colas de mensajería: Redis, RabbitMQ y Apache Kafka Decidir cómo mover el trabajo fuera de la ruta de la solicitud HTTP es un hito arquitectónico estándar. Pero elegir **cómo** enrutar ese trabajo puede llevar a una parálisis por análisis. No necesitas ejecutar un clúster de Kafka de tres nodos para enviar cincuenta correos de bienvenida al día, ni deberías construir un libro contable financiero en Redis Pub/Sub. El agente (broker) adecuado es un equilibrio entre **los requisitos de ordenación**, **las garantías de entrega**, **el rendimiento** y **la sobrecarga operativa (Ops) que tu equipo esté dispuesto a asumir**. **Guías relacionadas:** [High-load event ingestion](high-load-event-ingestion) · [Databases under load](database-performance-and-scaling) · [Observability and monitoring](observability-monitoring-laravel) ## Índice * [¿Por qué no usar una tabla de base de datos?](#why-not-db) * [Los tres modelos de mensajería](#three-models) * [Redis: simple, en memoria, baja latencia](#redis) * [RabbitMQ: agente inteligente, enrutamiento flexible](#rabbitmq) * [Apache Kafka: el registro de confirmación distribuido](#kafka) * [Matriz de comparación de características](#matrix) * [Garantías de entrega: Al menos una vez, Al sumo una vez, Exactamente una vez](#delivery) * [Ordenación, grupos de consumidores y escala](#ordering) * [Costo operativo: Gestionado frente a Autohospedado](#ops-cost) * [Errores comunes](#common-mistakes) * [Lista de verificación](#checklist) * [Cuestionario de autoevaluación](#self-test-quiz) --- ## ¿Por qué no usar una tabla de base de datos? Es tentador registrar las tareas (`jobs`) en PostgreSQL o MySQL, indexar la columna `status` y sondearla (polling) cada segundo. Para configuraciones de bajo volumen, esto **puede funcionar**. Sin embargo, a medida que el volumen crece, la base de datos se rompe bajo las cargas de trabajo de cola: * **Fragmentación de la tabla (Bloat)** — los motores de bases de datos no toleran bien los patrones constantes de escritura y posterior eliminación. Las tuplas muertas se acumulan, el autovacuum se retrasa y el rendimiento del índice se degrada. * **Contención de bloqueos por sondeo** — múltiples trabajadores que ejecutan `SELECT ... FOR UPDATE LIMIT 1` bloquean en escritura las mismas páginas de índice, lo que ralentiza el rendimiento. * **Inserción (Push) frente a Sondeo (Pull)** — las bases de datos te obligan a realizar sondeos; los agentes de mensajería empujan los mensajes a las conexiones TCP en espera al instante. --- ## Los tres modelos de mensajería 1. **Cola en memoria transitoria (Redis Lists / Pub/Sub)** — Rápida, ligera, los datos caben en la RAM, patrones simples. 2. **Cola de mensajes clásica (RabbitMQ / ActiveMQ)** — Enrutamiento complejo, las colas realizan el seguimiento del estado del consumidor, los mensajes se eliminan una vez confirmados. 3. **Flujo de eventos basado en logs (Kafka / Redpanda)** — Registro de confirmación de solo lectura al final (append-only) en disco, los mensajes persisten después de leerse, los consumidores realizan el seguimiento de sus propias posiciones (offsets). --- ## Redis: simple, en memoria, baja latencia Redis es un almacén de datos en memoria que admite primitivas de colas. ### Mecanismos * **Listas (`LPUSH` / `BRPOP`)** — Una cola FIFO básica. Simple, de baja latencia (microsegundos), pero carece de enrutamiento avanzado. * **Streams (Redis 5.0+)** — Agrega entradas a un log, admite grupos de consumidores y confirmaciones (`XACK`). * **Pub/Sub** — Difusión de tipo \"disparar y olvidar\" (fire-and-forget). Si no hay consumidores conectados cuando se publica un mensaje, el mensaje se **pierde**. ### Fortalezas * Cero infraestructura adicional si ya utilizas Redis para caché o almacenamiento de sesiones. * Latencia extremadamente baja. ### Debilidades * **Límites de RAM** — Si los trabajadores se ralentizan y la cola crece, puedes agotar la memoria del servidor. * **Compromisos de durabilidad** — La persistencia AOF/RDB escribe de forma asíncrona; un colapso repentino puede hacer que se pierdan los mensajes recientes. --- ## RabbitMQ: agente inteligente, enrutamiento flexible RabbitMQ es un agente AMQP (Advanced Message Queuing Protocol) basado en Erlang. ### Conceptos clave * Los **Productores** publican mensajes en **Exchanges**. * Los **Exchanges** enrutan mensajes a **Colas (Queues)** usando **Vinculaciones (Bindings)** (reglas basadas en claves de enrutamiento, encabezados o difusión/fanout). * Los **Consumidores** extraen los mensajes de las **Colas**. ``` Productor ──> [ Exchange ] ──(Reglas de vinculación)──> [ Cola ] ──> Consumidor ``` ### Fortalezas * Patrones de enrutamiento ricos (por ejemplo, coincidencia de temas/topics, enrutamiento por encabezados). * Semántica de confirmación (Ack / Negative-Ack) por mensaje. * Exchanges de mensajes fallidos (Dead Letter Exchanges o DLX) integrados para reintentos fallidos de inmediato. ### Debilidades * El **entorno de ejecución de Erlang** agrega sobrecarga operativa para la configuración y la gestión del clúster. * El rendimiento de la cola se degrada si las colas crecen a millones de mensajes y se desbordan al disco. --- ## Apache Kafka: el registro de confirmación distribuido Kafka no es una cola de mensajes tradicional. Es un registro de transacciones distribuido, particionado y de solo escritura al final (append-only). ### Conceptos clave * Los **Temas (Topics)** se dividen en **Particiones**. * Los mensajes se añaden secuencialmente en el disco. * Un mensaje se identifica por su **Offset** (posición de índice). * Los consumidores se unen a **Grupos de consumidores (Consumer Groups)**; Kafka asigna particiones a los miembros del grupo. ``` Tema: Pedidos Partición 0: [Msg 0][Msg 1][Msg 2][Msg 3] <-- Consumidor A (Offset 3) Partición 1: [Msg 0][Msg 1] <-- Consumidor B (Offset 1) ``` ### Fortalezas * **Alto rendimiento** — Las escrituras son secuenciales en el disco; las lecturas aprovechan la caché de páginas del sistema operativo y la transferencia de red sin copia (zero-copy). * **Reproducción de mensajes (Message Replay)** — Debido a que los mensajes persisten en el disco durante una ventana de retención establecida, puedes rebobinar los offsets y reproducir el historial. * **Escalabilidad** — El particionamiento permite el escalado horizontal en múltiples servidores (brokers). ### Debilidades * Alta complejidad. Requiere Apache ZooKeeper o KRaft para la coordinación. * Alta latencia en comparación con Redis (milisegundos frente a microsegundos). * Demasiado complejo para el procesamiento simple de tareas. --- ## Matriz de comparación de características | Característica | Redis (Lists) | RabbitMQ | Apache Kafka | |----------------|---------------|----------|--------------| | **Modelo principal** | Lista / Flujo en memoria | Agente inteligente (AMQP) | Registro de confirmación distribuido | | **Persistencia** | Volátil / Disco opcional | Disco/Memoria (configurable) | Siempre disco (Commit Log) | | **Rendimiento máx.**| Alto (limitado por CPU de un solo núcleo/RAM) | Moderado (decenas de miles/s) | Extremo (millones/s mediante particiones) | | **Vida del mensaje** | Eliminado al extraerlo (pop) | Eliminado después de Ack | Retenido por política de tiempo/tamaño | | **Flexibilidad de enrutamiento** | Ninguna (FIFO) | Alta (Exchanges & Bindings) | Mapeo clave a partición | | **Garantías de orden** | FIFO estricto | Estricto por cola (consumidor único) | Estricto **dentro de una partición** | --- ## Garantías de entrega Ningún sistema de mensajería puede garantizar la entrega \"exactamente una vez\" a través de los límites de la red sin una coordinación de transacciones distribuidas (lo que degrada el rendimiento). * **Al sumo una vez (At-most-once)** — Los mensajes se envían sin confirmación. Si ocurre un problema de red o un colapso, el mensaje se pierde. * **Al menos una vez (At-least-once)** — Los consumidores deben confirmar el procesamiento. Si ocurre un colapso a mitad del proceso, el agente entrega el mensaje nuevamente. **La lógica de tu aplicación debe ser idempotente** para manejar duplicados. * **Exactamente una vez (Exactly-once)** — Requiere coordinación de extremo a extremo (como las transacciones de Kafka). A menudo se simula combinando la entrega \"al menos una vez\" con la deduplicación en el destino. > [!NOTE] > **Regla de idempotencia** > Diseña siempre tus consumidores para manejar duplicados. Utiliza IDs de transacción únicos o claves de negocio para protegerte contra el procesamiento de un mismo evento dos veces. --- ## Ordenación, grupos de consumidores y escala * **RabbitMQ** garantiza el orden dentro de una sola cola. Si escalas a múltiples consumidores paralelos, procesan mensajes a diferentes velocidades, lo que puede resultar en una ejecución desordenada a nivel de aplicación. * **Kafka** garantiza el orden **solo dentro de una partición**. Para mantener el orden de un recurso (por ejemplo, actualizaciones del pedido #105), debes enrutar todos sus eventos a la misma partición utilizando una clave de partición (por ejemplo, `order_id`). --- ## Costo operativo: Gestionado frente a Autohospedado * **Redis** es fácil de ejecutar y administrar. Casi todos los proveedores de la nube ofrecen un servicio de Redis gestionado. * **RabbitMQ** requiere un monitoreo activo del uso de memoria de la cola, el espacio en disco y la sincronización del clúster de Erlang. Las opciones gestionadas (como CloudAMQP o AWS Amazon MQ) reducen esta carga. * **Kafka** es el más complejo de operar. Administrar los rebalanceos de particiones, la configuración del agente, la retención de disco y el consenso de KRaft es un rol operativo de tiempo completo. Utiliza plataformas gestionadas (como Confluent Cloud, AWS MSK o Aiven) a menos que tengas un equipo de infraestructura dedicado. --- ## Errores comunes 1. **Publicar eventos dentro de transacciones de base de datos**: Poner en cola un mensaje antes de confirmar la transacción de la base de datos. Si el consumidor se ejecuta más rápido que la confirmación del DB, buscará registros que aún no existen. 2. **Falta de límites de prebúsqueda (Prefetch) en RabbitMQ**: Dejar el límite de prebúsqueda predeterminado sin establecer. RabbitMQ enviará todos los mensajes de la cola al primer consumidor disponible, sobrecargándolo mientras otros trabajadores permanecen inactivos. 3. **Usar Kafka sin claves de partición**: Publicar eventos en Kafka sin especificar una clave de enrutamiento, lo que enruta los mensajes de forma aleatoria y rompe las garantías de ordenación para registros relacionados. 4. **Tratar Pub/Sub como una cola persistente**: Usar Redis Pub/Sub para tareas en segundo plano, asumiendo que los mensajes se almacenan en búfer cuando los consumidores están desconectados. --- ## Lista de verificación 1. **Verifica tu volumen:** ¿Menos de 10k mensajes/s? Omite Kafka; comienza con Redis o RabbitMQ. 2. **Define la durabilidad:** ¿Puedes permitirte perder un mensaje si el servidor se cae? Si no, evita las listas de Redis puramente en memoria. 3. **Comprueba los requisitos de enrutamiento:** ¿Necesitas patrones de enrutamiento complejos (por ejemplo, enrutamiento por temas)? Elige RabbitMQ. 4. **Establece límites de ordenación:** ¿Necesitas un orden estricto por entidad en trabajadores paralelos? Elige Kafka con claves de partición. 5. **Reconoce el costo operativo:** ¿Tiene tu equipo el tiempo y la capacidad para mantener KRaft/ZooKeeper? Si no, elige un servicio gestionado. --- ## Resumen La herramienta adecuada coincide con la forma de tus datos. Utiliza **Redis** para colas de tareas rápidas, **RabbitMQ** cuando la lógica de enrutamiento sea compleja y **Kafka** cuando necesites un registro de confirmación de alto rendimiento. --- ## Cuestionario de autoevaluación ### Pregunta 1: ¿Qué sucede con un miensaje en Redis Pub/Sub si no hay suscriptores activos conectados en el momento en que se publica? - A) Se pone en cola en memoria hasta que se conecte un suscriptor. - B) Se descarta y se pierde permanentemente. - C) Se escribe en el archivo de instantáneas RDB.
Mostrar respuestas **Respuesta: B** Redis Pub/Sub es un mecanismo de difusión de disparar y olvidar. No almacena mensajes en búfer para clientes desconectados; se pierden inmediatamente si no hay suscriptores activos.
--- ### Pregunta 2: En Apache Kafka, ¿cómo se asegura de que todas las actualizaciones de estado para un usuario específico se procesen en el orden exacto en que ocurrieron? - A) Ejecute un solo agente (broker). - B) Utilice el `user_id` como clave de partición para que todos los eventos de ese usuario terminen en la misma partición. - C) Establezca la retención del log en el infinito.
Mostrar respuestas **Respuesta: B** Kafka garantiza el orden de los mensajes solo dentro de una sola partición. Al usar el `user_id` como clave de partición, Kafka enruta todos los eventos para ese usuario a la misma partición, preservando el orden de ejecución.