Arquitectura Azure — Módulo 5: integración, Service Bus y los despertadores

Los principios de la columna de integración cierran la serie sin una enmienda: asíncrono entre servicios, DLQ en toda cola, idempotencia en todo consumidor, y el agente despertado por cola, evento o reloj. Azure los implementa con la cola más equipada de las tres nubes y un reparto de piezas que conviene tener claro.

Función	En AWS	En GCP	En Azure
Cola de trabajo	SQS	Pub/Sub (pull)	Service Bus (queues)
Publicar en abanico	SNS	Pub/Sub (multi-sub)	Service Bus (topics)
Bus de eventos con reglas	EventBridge	Eventarc	Event Grid
Cola austera de volumen	—	—	Storage Queues
Reloj / cron	EventBridge Scheduler	Cloud Scheduler	Cron de Container Apps jobs / Logic Apps
Puerta de APIs	API Gateway	API Gateway/Apigee	API Management (APIM)

La tesis del módulo

Service Bus trae de fábrica lo que en otras nubes era diseño artesanal — DLQ automática en cada cola, sesiones que garantizan orden y afinidad por entidad, deduplicación por ID, entrega programada — y ese equipamiento cambia el reparto de responsabilidades: parte de la disciplina que el consumidor cargaba se muda a la infraestructura. Lo que no se muda nunca: la idempotencia sigue siendo del consumidor, porque el mundo sigue entregando al menos una vez.

Service Bus: la cola enterprise

Las piezas: queues (cola clásica: uno procesa) y topics con suscripciones (abanico con filtros por suscripción — el evento “cotización enviada” llega filtrado a quien corresponde). Y el equipamiento que distingue a esta casa:

• DLQ integrada: cada cola y suscripción nace con su dead-letter — el argumento innegociable de la serie, aquí sin siquiera configurarlo. Lo que sigue siendo tuyo: la alarma encima (módulo 11) y el hábito de mirarla.
• Sesiones (sessions): mensajes con el mismo session ID procesados en orden y por el mismo consumidor. Para agentes es la finura mayor del módulo: la conversación del cliente X como sesión garantiza que sus mensajes no se procesen en paralelo desordenado — la afinidad conversacional que en SQS exigía colas FIFO con grupos y en Pub/Sub claves de orden, aquí con semántica pensada para el caso.
• Deduplicación por message ID en ventana temporal: el duplicado del productor descartado por la infraestructura. Reduce (no elimina) el trabajo de idempotencia: cubre el “publiqué dos veces”, no el “procesé dos veces tras un fallo post-proceso” — el consumidor idempotente sigue siendo ley.
• Entrega programada y aplazamiento: el mensaje que aparece a las 9:00, el reintento en 4 horas — parte del rol que Cloud Tasks jugaba en GCP, dentro de la cola.

Storage Queues es la alternativa austera (simple, baratísima, sin topics ni sesiones) para volúmenes brutos sin requisitos — legítima en pipelines internos de gran volumen; la plataforma de agentes típica vive mejor en Service Bus. Event Grid es el bus de eventos — los sucesos de la infraestructura Azure (el blob subido, el recurso creado) y los tuyos, enrutados por filtros hacia Container Apps, Functions o colas: el EventBridge/Eventarc local, con la misma misión de despertar.

      QUIÉN DESPIERTA AL AGENTE (AZURE)

  correo llega     cada noche 2am    blob subido
       │                │                │
       ▼                ▼                ▼
  ┌──────────┐   ┌─────────────┐   ┌───────────┐
  │ Service  │   │ cron del    │   │ Event     │
  │ Bus      │   │ Container   │   │ Grid      │
  │ (+DLQ)   │   │ Apps job    │   │ (filtro)  │
  └────┬─────┘   └──────┬──────┘   └─────┬─────┘
       │                │                │
       └───────────┬────┴────────────────┘
                   ▼
           ┌───────────────┐
           │ Container App │  KEDA escala
           │ / job (KEDA   │  por la cola
           │ por la cola)  │  (módulo 3)
           └───────────────┘

El cierre del cuadro es la conexión con el módulo 3: KEDA escalando por el largo de la cola de Service Bus es la unión más limpia de la serie entre mensajería y cómputo — el despertador y el músculo declarados como un solo comportamiento.

APIM en la puerta (y las herramientas, como siempre)

API Management es el portero de esta casa — autenticación, rate limits y cuotas por cliente, la primera línea contra el denial of wallet — con una particularidad que adelanta el módulo 7: APIM tiene un papel inusualmente protagónico en Azure como gateway de LLMs (políticas específicas para limitar tokens, balancear despliegues de modelos y registrar el uso), así que la pieza que aquí guarda la puerta de entrada reaparecerá guardando la puerta de salida hacia los modelos. Y las herramientas del agente cierran igual que siempre: APIs internas concretas — idealmente MCP — corriendo como microservicios de la plataforma, con su managed identity y su lugar en la VNet.

Ojo — el equipamiento no reemplaza el diseño: la tentación de Service Bus es usar todas las finuras porque están. Las sesiones serializan (adiós paralelismo dentro de cada sesión — correcto para la conversación del cliente X, incorrecto para el lote de 10.000 correos independientes); la deduplicación por ID cuesta throughput; la entrega programada no es un scheduler general. Cada finura se activa por una razón del caso, no por catálogo — el eco del “elegir forma de suscripción” de GCP: el poder está en elegir, no en encender todo.

Errores comunes

• Sesiones para todo. La afinidad ordenada donde no hace falta mata el paralelismo del consumidor. Sesiones para lo conversacional; cola plana para lo independiente.
• Confundir la dedup del broker con idempotencia. Service Bus descarta el duplicado del productor; el fallo post-procesamiento sigue reentregando. La clave de deduplicación en el consumidor no se jubila.
• DLQ nativa, alarma ausente. Que la cola muerta exista de fábrica no significa que alguien la mire. La alarma con acción del módulo 11 sigue siendo el trabajo.
• Storage Queues por ahorro reflejo. Barata hasta que necesitas topics, sesiones o dedup y los reconstruyes a mano encima. El ahorro se calcula con los requisitos completos.
• Event Grid como cola. Es un enrutador de eventos, no un buffer de trabajo con reintentos pacientes. Eventos por Grid, trabajo por Service Bus — la distinción evento/comando de la serie con nombres locales.
• APIM tarde. Servicios expuestos “mientras tanto” sin portero: cada uno improvisa auth y límites. La puerta se pone antes del tráfico, en todas las nubes.

La frase para llevarse

“Service Bus te regala lo que en otras nubes diseñabas — DLQ, orden por sesión, dedup del productor, entrega programada — pero regala herramientas, no criterio: cada finura se enciende por una razón del caso, la idempotencia sigue siendo del consumidor, y KEDA escalando por la cola cierra el círculo del trabajo que despierta cómputo.”

Qué viene

Módulo 6: estado y datos. El reparto por forma de acceso con las casas de Azure: Cosmos DB para sesiones (con búsqueda vectorial integrada — un giro en la decisión vectorial), Azure Database for PostgreSQL con pgvector, Blob Storage para objetos, y Azure AI Search — el buscador vector+híbrido que en el módulo 9 alimentará el grounding de los agentes.

Material relacionado

• Módulo 4: redes — la VNet del agente
• Módulo 6: estado y datos
• Curso de AWS — Módulo 5: microservicios y APIs
• Curso de GCP — Módulo 5: integración — Pub/Sub
• Fundamentos: MCP, el protocolo de las herramientas
• Glosario de Arquitectura Azure para Agentes de IA