D4 · Infraestructura

Mensajería y Eventos

Pregunta garantizada en el AZ-305: Storage Queue vs Service Bus vs Event Grid vs Event Hubs. La clave está en distinguir mensajes (comandos con valor por unidad) de eventos (notificaciones) y streams (telemetría masiva).

Contenido

Mensajes vs eventos — la distinción
Los 4 servicios comparados
Service Bus en profundidad
Event Grid en profundidad
Tabla de decisión

Mensajes vs eventos — la distinción

Mensaje (comando)

•"Procesa ESTE pedido" — el productor espera un procesamiento
•El payload ES el dato completo
•No puede perderse; orden y transacciones pueden importar
•→ Service Bus / Storage Queues

Evento (notificación)

•"Algo OCURRIÓ" (blob creado, VM eliminada)
•Payload ligero: referencia al hecho
•El productor no sabe ni le importa quién reacciona
•→ Event Grid

Stream (telemetría)

•Millones de eventos/segundo en flujo continuo
•El valor está en el AGREGADO, no en cada evento
•Consumidores releen con offsets
•→ Event Hubs

📨Árbol de decisión — Mensajería y Eventos

Storage Queue · Service Bus · Event Grid · Event Hubs

Interactivo

Pregunta 1

¿Qué patrón de comunicación necesitas?

💡 La distinción fundamental: mensajes = comandos con procesamiento garantizado por unidad. Eventos = notificaciones "algo ocurrió". Streams = telemetría masiva re-leíble.

Los 4 servicios comparados

Servicio	Paradigma	Diferenciadores	Anti-caso
Storage Queues	Cola simple	Barato, hasta 500 TB, mensajes 64 KB. Sin orden ni duplicate detection	FIFO, transacciones, pub/sub
Service Bus	Cola/tópicos enterprise	FIFO (sessions), dedup, transacciones, DLQ, tópicos pub/sub, AMQP. Premium: zonas + VNet	Telemetría masiva (caro por mensaje)
Event Grid	Eventos discretos push	Enrutado reactivo de eventos de servicios Azure y custom; filtros; push a handlers (Functions, webhooks); MQTT broker para IoT	Payloads grandes, garantías de cola de trabajo
Event Hubs	Streaming (log particionado)	Millones eventos/s, retención re-leíble, consumer groups, Kafka-compatible, Capture a storage	Comandos individuales con procesamiento garantizado por unidad

Service Bus en profundidad

Features que el examen señala

• Sessions: FIFO garantizado por sesión ("procesar en orden los mensajes de cada cliente")
• Duplicate detection: descarta reenvíos en una ventana temporal
• Dead-letter queue: mensajes envenenados apartados automáticamente
• Topics + subscriptions: pub/sub con filtros por suscripción
• Scheduled delivery, deferral, auto-forwarding

Modos de recepción y tiers

• Peek-lock (at-least-once con lock y complete/abandon) vs receive-and-delete (at-most-once)
• Standard (multi-tenant) vs Premium: Messaging Units dedicadas, zone-redundancy, private endpoints, mensajes 100 MB, geo-DR

Event Grid en profundidad

Fuentes y handlers

• Fuentes: Storage (blob created), Resource Groups (recurso creado/borrado), Key Vault (cert expirando), Event Hubs, custom topics, partner events (SAP, Auth0)
• Handlers: Functions, Logic Apps, webhooks, Service Bus, Event Hubs, Storage Queues
• Filtros por tipo de evento y subject — solo recibes lo que importa

Garantías

• Push at-least-once con reintentos 24h + dead-lettering a storage
• Patrón clásico: blob subido → Event Grid → Function procesa (reactivo, sin polling)
• "Auditar cada recurso creado en la suscripción" → Event Grid sobre el resource group/suscripción

Patrones combinados (muy de examen)

Los servicios se COMBINAN: Event Grid notifica "hay blob nuevo" → Function lo procesa → escribe comando en Service Bus → workers procesan con load leveling. O Event Hubs ingiere telemetría → Stream Analytics agrega → Event Grid dispara alertas. No son excluyentes.

Tabla de decisión

El escenario dice...	Respuesta
Pedidos procesados exactamente en orden por cliente	Service Bus con sessions (FIFO)
Eliminar mensajes duplicados por reintentos del emisor	Service Bus duplicate detection
Un pedido notifica a facturación, envíos y CRM a la vez	Service Bus topic con 3 subscriptions
Cola simple y barata para desacoplar, >80 GB	Storage Queues
Ejecutar una Function cuando se sube un blob	Event Grid → Function
Reaccionar a creación/borrado de recursos Azure	Event Grid (resource events)
1M eventos/s de telemetría IoT	Event Hubs
Apps Kafka sin reescribir	Event Hubs (endpoint Kafka)
Varios equipos releen el mismo stream a su ritmo	Event Hubs consumer groups
Mensajería con aislamiento de red y zonas	Service Bus Premium + private endpoints

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un sistema de pedidos requiere: (1) los pedidos de cada cliente deben procesarse en el orden exacto en que se enviaron, (2) los reintentos del cliente no deben generar pedidos duplicados, (3) los pedidos que fallen repetidamente deben apartarse para análisis sin bloquear la cola. ¿Qué servicio cumple los tres requisitos?

Inicia sesión para llevar tu progreso.

AnteriorDiseño de Contenedores y AKSInfraestructura SiguienteAPIs e IntegracionInfraestructura