Azure Event Grid: Roteamento de Eventos sem Polling

Um aviso de que algo aconteceu

Azure Event Grid distribui eventos discretos. Um produtor informa que um fato ocorreu — um blob foi criado, uma assinatura mudou ou um recurso foi provisionado — e um ou mais consumidores decidem como reagir. O emissor deixa de consultar destinos por polling e não precisa conhecer cada handler.

Essa semântica importa. “Arquivo criado” descreve passado; “processe este arquivo” ordena trabalho. Quando existe a expectativa de que um consumidor execute uma operação de negócio, uma fila de mensagens pode representar melhor o contrato.

Tópicos, assinaturas e filtros

Fontes nativas do Azure publicam em tópicos de sistema; aplicações usam tópicos personalizados ou domínios. Cada assinatura seleciona eventos e aponta para um handler, como Azure Functions, Logic Apps, Webhooks, Service Bus ou Event Hubs.

Filtros podem selecionar tipo do evento, início ou fim do assunto e propriedades do payload. Eles reduzem tráfego, mas devem depender de campos estáveis. Um filtro acoplado a um detalhe interno pode parar de encaminhar eventos depois de uma evolução aparentemente inofensiva.

flowchart LR
    Produtor["Serviço produtor"] --> Topico["Event Grid topic"]
    Topico --> FiltroA["Assinatura<br/>imagem criada"]
    Topico --> FiltroB["Assinatura<br/>arquivo excluído"]
    FiltroA --> Function["Azure Function"]
    FiltroA --> Logic["Logic App"]
    FiltroB --> Auditoria["Webhook de auditoria"]

CloudEvents oferece um envelope padronizado para origem, identificador, tipo e horário; o esquema nativo do Event Grid também é suportado. Padronizar o envelope facilita correlação, mas o payload de negócio ainda precisa de versão e compatibilidade.

Repetição exige idempotência

Event Grid aplica tentativas para falhas transitórias. Isso não significa “exatamente uma vez”. Um handler pode concluir seu efeito e falhar antes de confirmar a resposta, levando à entrega repetida. O identificador do evento deve participar de uma estratégia idempotente, por registro de processamento, restrição de unicidade ou operação naturalmente repetível.

Dead-letter pode encaminhar eventos não entregues a um armazenamento. Esse destino precisa de monitoramento, contexto para diagnóstico e procedimento de reprocessamento; sem isso, vira apenas uma área onde falhas ficam invisíveis.

Decisão	Recomendação
Resposta do webhook	Confirmar rapidamente e deslocar trabalho demorado
Duplicidade	Tratar id como chave idempotente
Evolução	Versionar tipo e contrato
Falha permanente	Enviar para dead letter e alertar o responsável
Segurança	Validar origem e evitar segredos no payload

O lugar do Event Grid

A comparação oficial dos serviços de mensagens do Azure separa três intenções: Event Grid reage a eventos; Event Hubs ingere streams reproduzíveis; Service Bus transporta mensagens de negócio com estado de entrega. Usar Event Grid como log histórico ou fila transacional força o serviço a um papel inadequado.

Ele se encaixa bem em automações de infraestrutura, integração serverless e propagação de eventos leves. Um evento de armazenamento pode disparar processamento de imagem; uma alteração de recurso pode iniciar auditoria; um fato do domínio pode avisar projeções independentes.

Contrato pequeno e verificável

Um evento útil contém identidade, tipo, versão, origem e dados mínimos para a reação. Payloads grandes devem permanecer em armazenamento apropriado, referenciados por URI protegida e identificador. Um correlationId ajuda quando o evento participa de uma jornada maior.

Event Grid reduz acoplamento temporal, mas produtor e consumidores ainda precisam concordar sobre significado, compatibilidade e tratamento de falhas. Com esse contrato explícito, o serviço deixa de ser apenas um disparador e passa a sustentar uma arquitetura reativa observável.