Colas, pub/sub y buses de eventos gestionados
Tres servicios que parecen el mismo y no lo son. Una cola reparte trabajo entre consumidores, un pub/sub entrega la misma noticia a varios interesados y un bus de eventos rutea por contenido. Elegir mal se paga en mensajes duplicados o perdidos.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
La primera vez que una aplicación necesita hacer algo “después” —mandar el mail, generar el PDF, avisarle a otro sistema— aparece la mensajería. Y con ella tres servicios del catálogo que suenan intercambiables.
No lo son, y la diferencia no es técnica sino de pregunta: ¿este mensaje lo procesa uno de varios trabajadores, o lo reciben todos los interesados?
Las tres formas
| Cola | Pub/sub | Bus de eventos | |
|---|---|---|---|
| Quién recibe cada mensaje | Exactamente un consumidor | Todos los suscriptores del tema | Los destinos cuya regla coincide |
| Quién decide el destino | Quien lee, tomando trabajo | Quien se suscribe al tema | Una regla sobre el contenido del evento |
| Para qué | Repartir y amortiguar trabajo | Avisar un hecho a varios sistemas | Integrar sistemas sin acoplarlos |
| Ejemplo | Generar mil PDFs con diez trabajadores | "Se creó un pedido": facturación, stock y correo | "Pago rechazado de más de 10.000" va a revisión |
| Necesidad | AWS | Google Cloud | Azure |
|---|---|---|---|
| Cola de trabajo | SQS | Cloud Tasks y Pub/Sub | Service Bus (colas) y Storage Queues |
| Publicación y suscripción por tema | SNS | Pub/Sub | Service Bus (temas y suscripciones) |
| Bus con ruteo por contenido | EventBridge | Eventarc | Event Grid |
| Flujo de datos de alto volumen y relectura | Kinesis Data Streams y MSK | Pub/Sub y Managed Kafka | Event Hubs |
La combinación más frecuente, y la que conviene conocer, es un tema con colas suscritas: el productor publica el hecho una sola vez, cada sistema interesado tiene su propia cola, y cada uno procesa a su ritmo sin que la lentitud de uno frene a los demás.
Antes de seguir, predecí
Entrega al menos una vez y qué significa para el código
Casi todos estos servicios garantizan al menos una vez: un mensaje puede llegar duplicado. No es un defecto, es la consecuencia de que la red falla y el sistema prefiere repetir antes que perder.
De dónde salen los duplicados
- El consumidor procesa el mensaje y se cae antes de confirmarlo.
- El plazo de visibilidad vence porque el procesamiento tardó más de lo configurado.
- El productor reintenta un envío que en realidad había llegado.
La única defensa que funciona es la idempotencia: que procesar el mismo mensaje dos veces tenga el mismo efecto que procesarlo una. Se logra con una clave de negocio —el id del pedido— guardada al procesar, y una verificación previa contra esa clave. No con “poner exactamente una vez” en la configuración.
Qué pasa con los mensajes que fallan siempre
Un mensaje que falla se reintenta. Si falla por un problema pasajero, el reintento lo resuelve. Si falla porque el mensaje es inválido, el reintento no lo va a arreglar nunca, y sin un mecanismo de escape se convierte en un ciclo infinito que consume capacidad y tapa los logs.
La configuración mínima de una cola de producción
- Reintentos con espera creciente, para no golpear una dependencia que ya está sufriendo.
- Cantidad máxima de intentos y, al superarla, envío a una cola de mensajes fallidos.
- Una alerta sobre esa cola: si tiene mensajes, alguien tiene que mirarlos. Una cola de fallidos que nadie mira es un agujero silencioso.
- Una forma de reprocesar: corregido el error, los mensajes vuelven a la cola original.
- Métrica de antigüedad del mensaje más viejo, que es la que avisa que los consumidores no dan abasto antes de que se empiecen a vencer.
Antes de seguir, predecí
Cuándo no alcanza una cola
Hay un cuarto tipo que aparece cuando el volumen crece: el flujo de datos. La diferencia con una cola es que el mensaje no se borra al leerlo; queda en el flujo durante una ventana de retención y cada consumidor lleva su propia posición de lectura.
| Cola | Flujo de datos | |
|---|---|---|
| Qué pasa al leer | Se consume y se borra | Queda; el consumidor avanza su posición |
| Releer lo pasado | No | Sí, mientras dure la retención |
| Paralelismo | Tantos consumidores como se quiera | Limitado por la cantidad de particiones |
| Caso típico | Trabajo asincrónico | Telemetría, clics, series de eventos, alimentar analítica |
Más a fondo · nivel seniorLa transacción que abarca la base y la cola
El problema más difícil de esta familia es que escribir en la base y publicar el mensaje son dos operaciones distintas: si la segunda falla después de la primera, el sistema quedó inconsistente y nadie se entera.
El patrón que lo resuelve es el buzón de salida: el mensaje se escribe en una tabla de la misma base, dentro de la misma transacción que el cambio de negocio, y un proceso aparte lee esa tabla y publica. Si el proceso se cae, republica al volver —de nuevo, al menos una vez, de nuevo la idempotencia del consumidor—. Lo que se gana es que no existe el caso “se guardó el pedido pero nadie se enteró”.
La variante sin tabla propia es leer el registro de cambios de la base con captura de datos de cambio, que evita el trabajo de escribir en dos lugares a costa de acoplarse al motor.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica