Microsoft AZ-204: Soluciones de mensajería y basadas en eventos de Azure — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

El portafolio de eventos y mensajería de Azure abarca cuatro servicios complementarios: Event Grid para la gestión de eventos reactivos, Event Hubs para la ingesta de streaming de alto rendimiento, Service Bus para la mensajería empresarial y la coordinación de flujos de trabajo, y Notification Hubs para notificaciones push móviles. Dominarlos requiere conocer las abstracciones principales de cada servicio, la semántica de entrega y reintentos, los modelos de escalado y cuándo preferir uno sobre otro en patrones de aplicación típicos como pub/sub, procesamiento de comandos, ingesta de telemetría y notificaciones a dispositivos o usuarios.

Event Grid: Temas, suscripciones, esquema, filtrado y mensajes fallidos (Dead-Lettering)

Event Grid es una red de pub/sub totalmente gestionada y basada en push para eventos discretos. Los publicadores envían eventos a un tema (topic); los suscriptores registran suscripciones de eventos en un tema y reciben los eventos que coinciden en manejadores (handlers) compatibles como webhooks HTTPS, Azure Functions, Logic Apps, Service Bus, Storage Queues y Event Hubs. Event Grid define dos modelos de publicador. Los temas del sistema (System topics) son recursos de tema gestionados por Azure que representan servicios de Azure de origen que publican eventos dentro de su suscripción o grupo de recursos (por ejemplo, la creación de un blob en Storage, la rotación de un secreto en Key Vault o eventos de Resource Manager). Los temas personalizados (Custom topics) son puntos de conexión de tema creados por el usuario a los que publican sus aplicaciones, permitiendo patrones orientados a eventos en sus propios servicios y dominios. Los temas del sistema no requieren código de publicador y simplifican la conexión de recursos de Azure a manejadores reactivos; los temas personalizados le dan control total sobre los contratos y el ciclo de vida de los eventos.

Los eventos de Event Grid pueden usar el esquema nativo de Event Grid o la especificación CloudEvents v1.0. Con el esquema de Event Grid, cada evento incluye id (identificador único), eventType (la acción), subject (ruta jerárquica que admite filtrado), eventTime (UTC), data (la carga útil o payload), dataVersion, metadataVersion y topic. CloudEvents proporciona un conjunto estandarizado de atributos como id, source, type, time, subject y data. Elegir CloudEvents facilita la interoperabilidad entre plataformas; el esquema de Event Grid mantiene la paridad con los eventos originados en Azure y un filtrado enriquecido sobre el campo subject.

Las suscripciones de eventos definen el enrutamiento, las opciones de entrega y los filtros. Los filtros básicos incluyen la inclusión por tipo de evento y el prefijo/sufijo del campo subject (subjectBeginsWith, subjectEndsWith), que son eficientes para la nomenclatura jerárquica de recursos. Los filtros avanzados realizan coincidencias en campos del evento de nivel superior o dentro de los datos (por ejemplo, comparaciones de rangos numéricos, contención de cadenas sin distinción de mayúsculas y minúsculas, igualdad booleana y contención en arreglos). Puede combinar filtros para un control preciso de la distribución (fan-out), minimizando el trabajo posterior y el egreso de datos.

La entrega es de tipo push con semántica de “al menos una vez” (at-least-once). Event Grid realiza reintentos con un retroceso exponencial (exponential back-off). Puede configurar el número máximo de reintentos y el tiempo de vida del evento (time-to-live); cuando la entrega falla definitivamente o el evento caduca, Event Grid puede enviar el evento a una cola de mensajes fallidos (dead-letter) en un contenedor de Blob Storage que usted designe en la suscripción. El envío a la cola de mensajes fallidos (dead-lettering) preserva las cargas útiles y los metadatos para auditoría o reprocesamiento; utilice un proceso separado para rehidratar y reproducir los eventos si es necesario. Los puntos de conexión de webhook participan en un protocolo de enlace de validación (validation handshake) para demostrar su propiedad, y para redes con restricciones puede preferir puntos de conexión gestionados de Azure (Functions, Service Bus, Storage Queue) que no necesitan exposición pública y pueden usar autorización respaldada por Azure AD.

Event Hubs: Particiones, Grupos de Consumidores, Rendimiento, Captura y Consumo Fiable

Event Hubs ingiere flujos de telemetría y registros de gran volumen con baja latencia. Los datos se anexan a particiones, que son registros de confirmación (commit logs) ordenados e independientes. Las particiones se eligen en el momento de la creación para paralelizar el rendimiento (throughput); los productores asignan una clave de partición para preservar el orden por clave, y el servicio asigna las claves a las particiones mediante una función hash. Múltiples lectores pueden procesar particiones en paralelo; dentro de una partición, el orden está garantizado.

Los grupos de consumidores proporcionan vistas independientes del flujo de datos, permitiendo que diferentes aplicaciones de procesamiento mantengan sus propias posiciones sin interferir entre sí (por ejemplo, un detector de anomalías en tiempo real y una canalización de archivado). Escalar los lectores horizontalmente requiere un equilibrio en la propiedad de las particiones; el EventProcessorClient del SDK coordina la asignación y el reequilibrio de particiones entre las instancias.

Las Unidades de rendimiento (Throughput Units o TU) en el nivel Standard definen la capacidad: cada TU otorga cuotas de ancho de banda de entrada (ingress) y de salida (egress). La característica Auto-inflate puede escalar las TU automáticamente para satisfacer los picos de demanda. El nivel Premium utiliza Unidades de procesamiento (Processing Units) con cómputo dedicado y latencia predecible. Supervise las métricas de limitación (throttling) para validar el aprovisionamiento. Event Hubs es compatible con el protocolo Kafka en el mismo punto de conexión, lo que simplifica la migración lift-and-shift de clientes de Kafka sin necesidad de ejecutar brokers.

Los productores pueden usar AMQP o HTTPS. AMQP (incluido AMQP-over-WebSockets en el puerto 443) proporciona conexiones multiplexadas y persistentes y un procesamiento por lotes eficiente, y se recomienda tanto para enviar como para recibir. HTTPS es adecuado para envíos simples o esporádicos, pero no es compatible para la recepción; el long-polling no está disponible, y se sacrifica la eficiencia y el control de flujo. En redes corporativas restringidas, AMQP-over-WebSockets preserva el rendimiento al pasar a través de los proxies de salida típicos.

La creación de puntos de control (checkpointing) y la gestión de offsets son fundamentales para la correctitud. Cada evento tiene un número de secuencia y un offset por partición. Los receptores avanzan a través del flujo y, tras procesar un lote con éxito, guardan un punto de control de su posición en un almacenamiento duradero, comúnmente un contenedor de Azure Blob Storage a través del EventProcessorClient. En un reinicio o una conmutación por error (failover), el procesador reanuda desde el último punto de control, logrando un procesamiento de al menos una vez (at-least-once) con manejadores idempotentes. Sin puntos de control, los consumidores comienzan desde una posición predeterminada (la más reciente o la más antigua) y corren el riesgo de reprocesar u omitir eventos.

La característica Capture proporciona archivado del lado del servidor al escribir automáticamente archivos Avro por lotes y de solo anexión (append-only) en Azure Blob Storage o Azure Data Lake Storage Gen2, según una ventana configurable de tiempo o tamaño. Esto elimina la necesidad de crear procesadores de lotes personalizados para análisis de ruta fría (cold-path), permitiendo que herramientas posteriores (como Spark o Synapse) consuman segmentos de flujo inmutables con una semántica de exactamente una vez (exactly-once) en relación con la canalización de captura.

Service Bus y Queue Storage: Comandos, Flujos de Trabajo, Sesiones y Manejo de Mensajes Fallidos

Service Bus es un agente de mensajes de nivel empresarial para comandos, flujos de trabajo y escenarios de integración que necesitan garantías de entrega enriquecidas. Las colas implementan mensajería punto a punto; un consumidor competidor recibe cada mensaje. Los temas con suscripciones habilitan el patrón pub/sub: los publicadores envían a un tema y suscripciones independientes reciben copias basadas en reglas. Las reglas de suscripción pueden ser filtros SQL, filtros de correlación o filtros booleanos verdaderos que computan la inclusión por mensaje y pueden agregar o modificar propiedades del mensaje mediante acciones.

Las sesiones proporcionan un procesamiento ordenado y exclusivo para mensajes relacionados. Asigne un SessionId en los mensajes que pertenecen a un mismo grupo (por ejemplo, todos los pasos en el Pedido 123). Un receptor acepta el bloqueo de la sesión y procesa los mensajes en orden de llegada para esa sesión, manteniendo un estado de sesión opcional, y luego libera la sesión para permitir que el siguiente consumidor tome posesión. Este es el patrón preferido para FIFO a escala. Sin sesiones, el orden no está garantizado entre consumidores competidores.

Service Bus admite los modos PeekLock y ReceiveAndDelete. PeekLock es el predeterminado para la fiabilidad: un consumidor bloquea un mensaje durante la duración del bloqueo, lo procesa y luego lo liquida con Complete. Si el procesamiento falla, el consumidor puede usar Abandon (haciéndolo disponible de nuevo), Defer (posponer su recuperación para más tarde por número de secuencia) o Dead-letter (moverlo a la subcola de mensajes fallidos separada de la entidad con el motivo y la descripción del error). ReceiveAndDelete intercambia fiabilidad por rendimiento al eliminar el mensaje inmediatamente después de su recepción.

Propiedades clave controlan el ciclo de vida. El Time to Live (TTL) se puede establecer por defecto en la entidad y anularse por mensaje; los mensajes caducados se envían a la cola de mensajes fallidos o se descartan según la configuración. La duración del bloqueo controla cuánto tiempo permanece bloqueado un mensaje para su procesamiento; el SDK puede renovar automáticamente los bloqueos para trabajos largos dentro de los límites máximos. El recuento máximo de entregas se configura por cola o suscripción; después de esa cantidad de intentos de entrega (Abandon o pérdida de bloqueo), el mensaje se mueve automáticamente a la cola de mensajes fallidos (DLQ). Los operadores vacían la DLQ para diagnósticos o reprocesamiento con lógica correctiva.

Azure Queue Storage es un servicio de colas más simple y masivamente escalable con una interfaz REST, ideal para desacoplamiento básico, alta distribución (fan-out) y cargas de trabajo sensibles al costo. Proporciona entrega de al menos una vez, un tiempo de espera de visibilidad para ocultar mensajes durante el procesamiento y un TTL por mensaje (predeterminado de 7 días, configurable, incluyendo la no caducidad). Los mensajes individuales tienen un tamaño limitado, y características como sesiones, transacciones, garantías de orden, detección de duplicados, subcolas de mensajes fallidos y filtros avanzados no están disponibles. Elija Queue Storage para trabajos simples en segundo plano y un rendimiento muy alto a bajo costo. Elija Service Bus cuando necesite enrutamiento sofisticado (temas/suscripciones), FIFO a través de sesiones, entrega programada, aplazamiento, transacciones entre entidades, ventanas de detección de duplicados, soporte para AMQP, o cuando la fiabilidad y la gobernanza de la integración sean importantes. Un patrón común es concentrar eventos ligeros a través de Event Grid o Queue Storage y coordinar comandos críticos para el negocio y transiciones de estado en Service Bus.

Notification Hubs: Enrutamiento de notificaciones push y gestión de credenciales de plataforma

Notification Hubs es un motor de notificaciones push multiplataforma que gestiona los registros de dispositivos a escala y enruta notificaciones dirigidas a Apple (APNs), Android (FCM), Windows (WNS) y otras plataformas. Las aplicaciones registran dispositivos usando etiquetas y expresiones de etiquetas, lo que permite una selección precisa de la audiencia (por ejemplo, user:42 AND region:emea OR topic:promotions). Las plantillas le permiten enviar una única carga útil localizada que los renderizadores específicos de la plataforma expanden, reduciendo la lógica del servidor y permitiendo la personalización por dispositivo con una ramificación mínima en el backend. El modelo de Instalación (Installation model) agiliza la gestión del ciclo de vida del dispositivo al encapsular el identificador de la plataforma, las etiquetas y las plantillas en un único recurso por dispositivo.

La gestión de credenciales de plataforma es fundamental para una entrega fiable. Para APNs, cargue credenciales basadas en certificados o en tokens (con Key ID, Team ID y el token .p8) y elija puntos de conexión de sandbox o de producción por hub o por espacio de nombres para segregar los entornos. Para FCM, configure las credenciales de servidor adecuadas (para HTTP v1, use una cuenta de servicio de Google con ámbitos de OAuth2). Para WNS, registre la aplicación para obtener el Package SID y el secreto de cliente. Las credenciales rotan periódicamente; programe la rotación y supervise los canales de retroalimentación (feedback) en busca de identificadores de dispositivo no válidos. Notification Hubs utiliza SAS para la autenticación a nivel de hub desde el servidor de su aplicación, mientras que los roles de Azure AD protegen las operaciones de gestión. Utilice convenciones de etiquetado para particionar aplicaciones multi-inquilino (multi-tenant) y limitar los envíos con notificaciones push programadas o por lotes para cumplir con las cuotas de la plataforma.

Escenario de problema práctico

Starbucks está implementando una experiencia global de pedidos móviles que debe notificar a los clientes cuando los pedidos están listos, procesar los pasos del flujo de trabajo del barista de forma fiable y analizar la telemetría de los equipos para un mantenimiento proactivo.

1. Conectar el ciclo de vida de los pedidos basado en eventos con Event Grid

• Cree un tema personalizado de Event Grid llamado OrderEvents y publique eventos de dominio discretos como OrderPlaced, PaymentAuthorized y OrderReady. Use rutas de asunto como /stores/{storeId}/orders/{orderId} para permitir el filtrado por prefijo por tienda. Configure suscripciones: una a un tema de Service Bus para el procesamiento del flujo de trabajo y otra a una Azure Function para un enriquecimiento ligero. Se elige Event Grid por su distribución ramificada (fan-out) de baja latencia, la normalización de esquemas (CloudEvents) y el filtrado eficiente que evita invocaciones innecesarias en los sistemas de destino (downstream).

2. Coordinar el flujo de trabajo del barista con temas y sesiones de Service Bus

• Defina un tema de Service Bus llamado Orders con suscripciones por cada etapa de procesamiento (Preparación, Entrega), cada una con filtros de correlación o SQL sobre eventType. Publique comandos como mensajes con SessionId = {orderId} para garantizar el procesamiento FIFO por pedido. Los consumidores usan PeekLock con renovación automática del bloqueo y ejecutan Complete en caso de éxito; en caso de fallo transitorio, Abandon desencadena un reintento; en caso de fallo persistente o mensajes dudosos (poison messages), el recuento máximo de entregas (Max delivery count) los mueve a la DLQ para su posterior inspección. El TTL en los mensajes específicos de cada etapa evita el trabajo obsoleto después del cierre de la tienda. Se elige Service Bus por su manejo de comandos ordenado y fiable, su liquidación (settlement) enriquecida y su modelo pub/sub basado en reglas.

3. Ingerir y archivar la telemetría de los equipos con Event Hubs

• Aprovisione un Event Hub llamado Telemetry con suficientes particiones para paralelizar por deviceId y habilite el inflado automático de TUs para absorber los picos. Los gateways de los dispositivos envían datos a través de AMQP-over-WebSockets para atravesar los proxies corporativos de manera eficiente. Use el EventProcessorClient con puntos de control (checkpointing) en Blob Storage para ejecutar la detección de anomalías y las alertas casi en tiempo real. Habilite la Captura (Capture) a ADLS Gen2 para archivos Avro inmutables que soporten análisis sin conexión en Synapse. Se elige Event Hubs por su ingesta sostenida de alto rendimiento con desplazamientos (offsets) duraderos y su fácil exportación a la ruta fría (cold-path).

4. Dirigir notificaciones push con Notification Hubs

• Registre los dispositivos móviles utilizando el modelo de Instalación (Installation model), etiquetando cada uno con user:{userId}, store:{storeId} y etiquetas de plataforma. Cargue las credenciales de token de APNs para iOS y la cuenta de servicio de FCM para Android; separe los hubs de desarrollo y producción para aislar las credenciales y la retroalimentación (feedback). Cuando llegan los eventos OrderReady, la Azure Function envía una única notificación de plantilla a Notification Hubs dirigida a las etiquetas user:{userId} AND store:{storeId}. Se elige Notification Hubs por su enrutamiento agnóstico a la plataforma, sus expresiones de etiquetas y la gestión centralizada de credenciales a escala global.

5. Garantizar la observabilidad y la resiliencia

• Configure el envío a colas de mensajes fallidos (dead-lettering) de Event Grid a un contenedor de Blob para retener los eventos no entregables para auditoría y reproducción. Supervise las DLQs de Service Bus y exponga un flujo de trabajo de operador para clasificar y volver a encolar los mensajes corregidos. Realice un seguimiento del retraso del consumidor (consumer lag) de Event Hubs a través de métricas para validar los puntos de control (checkpointing) y escalar horizontalmente los procesadores cuando el trabajo pendiente (backlog) crece. Esta combinación proporciona durabilidad de extremo a extremo: entrega “al menos una vez” (at-least-once) con rutas de reproducción para condiciones excepcionales, manteniendo al mismo tiempo la ruta principal (happy path) rápida y rentable.

Esta arquitectura separa claramente las responsabilidades: Event Grid impulsa la orquestación reactiva, Service Bus garantiza la corrección y el orden del flujo de trabajo, Event Hubs gestiona la telemetría continua a escala y Notification Hubs entrega notificaciones precisas y específicas de la plataforma a los clientes con una complejidad mínima en el backend.

← Gestión de API de Azure · Todos los dominios · Almacenamiento en caché →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →