¿Por qué necesitas un broker de mensajería?

01 — El escenario

Situación real

Tienes un SaaS de gestión de reservas. Cuando un usuario confirma una reserva, tu sistema necesita hacer tres cosas:

Enviar un email de confirmación, generar la factura y registrar la operación en el log de auditoría.

Hasta aquí, nada raro. El problema es cómo lo haces.

02 — Sin broker: todo síncrono

La solución más directa es que el mismo servidor que recibe la petición haga todo el trabajo de forma secuencial:

1. User hace click en “Confirmar reserva” → POST /booking
2. El servidor guarda la reserva en base de datos
3. Llama al servicio de email y espera respuesta — 1.2s
4. Genera la factura en PDF — 0.8s
5. Escribe el log de auditoría — 0.3s
6. Recién ahora responde al usuario — ~2.5s total

El problema no es que tarde 2.5 segundos.

El problema es que mientras procesa esa reserva, el servidor está bloqueado. Si 50 usuarios hacen lo mismo al mismo tiempo, tienes 50 hilos ocupados generando PDFs y enviando emails. El login empieza a tardar. El dashboard no carga. Todo se degrada.

No es un problema de Kafka, ni de RabbitMQ, ni de ninguna tecnología concreta. Es un problema de diseño: estás usando el mismo recurso (tu servidor) para dos cosas que tienen ritmos distintos — responder al usuario (tiene que ser rápido) y procesar tareas pesadas (puede esperar).

03 — Con broker: desacoplamiento

La idea es simple: separar “recibir la petición” de “procesarla”. El servidor recibe la reserva, la guarda, encola un mensaje diciendo “hay trabajo pendiente” y responde al instante. Otro proceso se encarga del trabajo pesado por separado.

1. User hace click en “Confirmar reserva”
2. El servidor guarda la reserva en base de datos
3. Envía al broker un mensaje: "booking.created · ID 4821"
4. El broker guarda el mensaje en una cola
5. El servidor responde al usuario → ~120ms
6. El broker entrega el mensaje a otro proceso que envía el email, genera la factura y escribe el log

Flujo: Users → Producer → Broker → Consumer

04 — ¿Qué ganas?

Respuesta rápida. La request del usuario responde en milisegundos, no en segundos. La experiencia mejora inmediatamente.

Servidor libre. El proceso que atiende HTTP no gasta recursos en tareas pesadas. Login, dashboard, API — todo sigue respondiendo normal.

Escalado independiente. Si necesitas procesar más emails, escalas los consumers sin tocar el servidor principal. Si el consumer se cae, los mensajes esperan en la cola.

Resiliencia. Si el servicio de email falla a las 3AM, la tarea no se pierde. El broker la guarda. Cuando el servicio vuelve, procesa todo lo pendiente.

05 — Las reglas del juego

Un broker no simplifica tu sistema. Lo hace más robusto cuando empieza a crecer. Pero introduce complejidad que tienes que gestionar:

El flujo es asíncrono. El usuario recibe un “OK” antes de que el email se haya enviado. Necesitas diseñar para eso: estados intermedios, notificaciones de progreso, feedback visual.

Idempotencia. Si el consumer procesa un mensaje y se cae antes de confirmarlo, el broker lo reintentará. Tu lógica tiene que soportar recibir el mismo mensaje dos veces sin duplicar la factura o enviar dos emails.

Reintentos y DLQ. ¿Qué pasa si un mensaje falla una, dos, cinco veces? Necesitas una estrategia: reintentos con backoff, y una Dead Letter Queue donde caigan los mensajes que ya no tienen remedio — para que un humano los revise.

Observabilidad. Ahora tienes una cola en medio. Necesitas monitorizar el lag (cuántos mensajes están pendientes), la tasa de errores y el throughput de tus consumers.

Un broker no es una bala de plata. Es una herramienta de diseño. Te permite separar lo urgente de lo importante, y escalar cada parte por separado.

06 — ¿Y qué broker uso?

Este artículo es intencionalmente agnóstico. El patrón de desacoplamiento con un broker aplica igual con RabbitMQ, Kafka, Amazon SQS o cualquier otro. La pregunta de cuál elegir depende de un segundo nivel de decisiones: ¿necesitas persistencia? ¿replay de eventos? ¿múltiples consumidores leyendo el mismo mensaje? ¿ordenamiento garantizado?

Eso es exactamente lo que exploramos en la segunda parte, donde comparamos una cola de mensajería tradicional con un distributed log como Kafka — y por qué para ciertos escenarios la diferencia es crítica.