Event gateway vs. message broker: quando usar cada um

Event gateways e message brokers lidam com comunicação assíncrona. Os dois recebem eventos ou mensagens, os dois desacoplam produtores de consumidores e os dois oferecem garantias de entrega. À primeira vista, parecem resolver o mesmo problema.

Não resolvem. Um message broker é infraestrutura que você opera (ou paga para alguém operar) para comunicação interna entre serviços. Um event gateway é uma plataforma gerenciada que cuida de todo o ciclo de vida dos eventos (ingestão, verificação, filtragem, transformação, roteamento, entrega e recuperação), com foco em ligar sistemas externos à sua arquitetura interna.

Entender essa fronteira importa porque times recorrem com frequência a um broker como Kafka ou RabbitMQ quando o que precisam de fato é de gestão do ciclo de vida dos eventos — ou tentam encaixar o tratamento de webhooks na infraestrutura do broker e acabam construindo uma camada de integração frágil e caseira em cima dela.

Este guia cobre o que cada tecnologia faz, como elas diferem em termos de arquitetura e como decidir de qual delas o seu sistema precisa — ou se você precisa das duas.

O que é um message broker?

Um message broker é um middleware que recebe mensagens de produtores, armazena essas mensagens temporariamente e as roteia para consumidores. Ele desacopla os serviços que geram dados dos serviços que os processam — o produtor não precisa saber quem são os consumidores, e os consumidores não precisam estar disponíveis no momento em que uma mensagem é publicada.

A abstração central varia de broker para broker. Em sistemas baseados em filas, como o RabbitMQ, as mensagens entram em uma queue e são consumidas por um único worker (ou por um grupo de workers concorrentes). Assim que uma mensagem recebe o acknowledgement, ela sai da queue. Em sistemas baseados em log, como o Apache Kafka, as mensagens são acrescentadas a um log ordenado e particionado. Os consumidores leem o log no próprio ritmo usando offsets, e os dados persistem de acordo com uma política de retenção — o que permite que vários consumidores leiam o mesmo stream de forma independente.

Message brokers foram projetados para comunicação interna entre serviços, dentro de arquiteturas que você controla. Tanto o produtor quanto o consumidor falam o protocolo nativo do broker (AMQP no RabbitMQ, o wire protocol do Kafka, STOMP no ActiveMQ), e normalmente ambos são serviços que você mesmo escreveu e implantou.

Capacidades centrais de um message broker

Persistência e durabilidade das mensagens. Brokers armazenam mensagens em disco para que elas sobrevivam a reinicializações, quedas ou indisponibilidade dos consumidores. No Kafka, as mensagens são retidas por um período configurável, independentemente do consumo. No RabbitMQ, filas duráveis mantêm as mensagens até que um consumidor confirme o recebimento.

Entrega pub/sub e ponto a ponto. Brokers suportam vários padrões de mensageria. A semântica ponto a ponto (queue) entrega cada mensagem a exatamente um consumidor. A semântica de publicação/assinatura (topic) entrega as mensagens a todos os consumidores inscritos. O modelo de consumer groups do Kafka mistura os dois: vários consumidores dentro de um grupo dividem a carga, enquanto grupos diferentes recebem cada um uma cópia completa do stream.

Garantias de ordenação. O Kafka oferece ordenação estrita dentro de uma partição — mensagens com a mesma chave de partição são sempre processadas em sequência. O RabbitMQ oferece ordenação dentro de uma única queue. Essas garantias são importantes em casos de uso em que a ordem de processamento afeta a corretude, como transações financeiras ou transições de máquinas de estado.

Controle de fluxo pelo consumidor. Os consumidores puxam as mensagens no próprio ritmo, o que naturalmente evita sobrecarga. Consumidores Kafka avançam o offset conforme processam. O RabbitMQ suporta limites de prefetch para controlar quantas mensagens não confirmadas um consumidor pode segurar de uma vez.

Alto throughput para cargas internas. O Kafka foi construído para volume — normalmente lida com centenas de milhares a milhões de mensagens por segundo em tópicos particionados. O RabbitMQ lida com dezenas de milhares de mensagens por segundo e é otimizado para distribuição de tarefas com menor latência. Os dois escalam horizontalmente por meio de clustering e particionamento.

Dead letter queues. Quando um consumidor rejeita uma mensagem ou o processamento falha repetidamente, a mensagem pode ser roteada para uma dead letter queue para inspeção, alerta ou reprocessamento manual. Esse é o principal mecanismo de recuperação de falhas do broker.

Casos de uso comuns de message brokers

Message brokers se destacam em comunicação interna entre serviços, de alto volume:

• Distribuição de tarefas: espalhar trabalho por um pool de workers — processamento de imagens, envio de e-mails, geração de relatórios — em que cada job deve ser tratado por exatamente um consumidor.
• Streaming de eventos e pipelines de analytics: alimentar sistemas de analytics, indexação de busca ou machine learning com dados em tempo real vindos dos serviços da aplicação. A retenção em log do Kafka o torna especialmente adequado a isso — vários times podem consumir o mesmo stream de eventos de forma independente.
• Desacoplamento de serviços: permitir que serviços internos se comuniquem sem dependências diretas. O serviço de pedidos publica um evento, e os serviços de estoque, cobrança e notificações consomem esse evento cada um por conta própria.
• CQRS e event sourcing: usar o log durável do broker como fonte da verdade para mudanças de estado, com visões otimizadas para leitura construídas a partir do stream de eventos.

Plataformas populares de message broker incluem Apache Kafka, RabbitMQ, Amazon SQS/SNS, Amazon EventBridge, Google Cloud Pub/Sub, Azure Service Bus, Apache Pulsar e NATS.

O que é um event gateway?

Um event gateway ocupa uma camada diferente da stack em relação a um message broker. Em vez de fornecer primitivas brutas de mensageria sobre as quais os seus serviços são construídos, ele oferece um pipeline completo e gerenciado de ingestão, processamento e entrega de eventos — com HTTP como transporte padrão.

Um message broker te dá topics, queues e mecânica de consumer groups. Você entra com o código de integração, a tradução de protocolo, a lógica de verificação, os adaptadores de payload, as políticas de retry e a stack de monitoramento. Um event gateway empacota tudo isso em uma única plataforma. Você declara sources, destinations, filtros e transformações; o gateway cuida de todo o resto.

Isso torna os event gateways especialmente adequados às fronteiras da sua arquitetura — os pontos em que os eventos cruzam entre sistemas que você controla e sistemas que você não controla. Webhooks externos, integrações com parceiros, notificações para clientes e conexões com serviços de terceiros são todos cenários em que o custo operacional de um broker não se justifica e a complexidade de integração é o problema de verdade. Para um olhar mais aprofundado sobre a categoria de produto e suas origens, veja a nossa introdução ao event gateway.

Capacidades centrais de um event gateway

HTTP como transporte padrão. Enquanto brokers exigem que produtores e consumidores adotem um protocolo nativo (AMQP, o wire protocol do Kafka), um event gateway opera nativamente sobre HTTP. Webhooks, callbacks REST e requisições de APIs assíncronas chegam sem tradução de protocolo. Isso elimina a ponte entre API gateway e broker que os times, de outra forma, teriam que construir e manter quando eventos externos precisam chegar a consumidores atendidos pelo broker.

Verificação específica por provedor. Um broker pressupõe confiança interna — as mensagens vêm de serviços que você implantou. Um event gateway pressupõe desconfiança externa. Ele valida assinaturas usando o esquema que cada provedor exige (HMAC-SHA256 da Stripe, header secreto do GitHub, rotação de chaves da Shopify) no nível da plataforma, de modo que a lógica de verificação não vaze para o código dos seus consumidores.

Filtragem sensível ao conteúdo. Brokers roteiam por topic ou queue — canais estruturais que você define de antemão. Um event gateway vai além, avaliando o conteúdo de cada evento contra regras de filtro definidas sobre headers, metadados e campos do payload. Eventos que não atendem aos critérios de um destination nunca saem do gateway, o que significa que os serviços downstream não gastam computação descartando mensagens irrelevantes.

Transformações que fazem a ponte entre schemas. Sistemas externos não publicam no seu schema. Um event gateway reestrutura payloads entre o recebimento e a entrega — renomeando campos, achatando estruturas aninhadas, mapeando entre formatos — para que os consumidores vejam um formato consistente, independentemente de qual provedor produziu o evento. Em uma arquitetura com broker, esse trabalho recai sobre serviços adaptadores customizados implantados ao lado do broker.

Roteamento declarativo e fan-out. Você configura quais eventos vão para onde com base em origem, tipo ou conteúdo. Enviar um evento para um novo destination significa adicionar uma regra de roteamento, não implantar um novo consumidor nem reconfigurar assinaturas de topics. O fan-out para vários destinations é uma operação no nível da plataforma, e não um exercício de coordenação de consumer groups.

Entrega push com retries gerenciados. Diferentemente de um broker, em que os consumidores puxam as mensagens, um event gateway envia os eventos por push para destinations HTTP e assume o resultado da entrega. Falhas disparam retries automáticos com backoff configurável. Entregas que falham de forma persistente aparecem como issues estruturadas e pesquisáveis — um padrão mais acionável do que rotear mensagens para uma dead letter queue que exige scripts customizados para inspecionar e reprocessar.

Replay como recurso de primeira classe. Depois de uma indisponibilidade, você seleciona um intervalo de tempo e reenvia todos os eventos afetados para o destination que estava fora do ar. Isso é uma ação operacional — um clique ou uma chamada de API — e não um reset manual de offset ou um pipeline de reprocessamento de DLQ que você constrói e mantém.

Visibilidade integrada do ciclo de vida. Observabilidade em broker significa costurar métricas de consumer lag, logs de aplicação e traces distribuídos vindos de ferramentas separadas. Um event gateway acompanha cada evento da chegada até a entrega em uma única timeline pesquisável: o que foi recebido, como foi filtrado e transformado, para onde foi roteado e o resultado de cada tentativa de entrega.

Rate limiting por destination. O gateway controla o ritmo de entrega por destination, protegendo os consumidores de picos de tráfego sem descartar eventos na ingestão. É comparável ao limite de prefetch de um consumidor no RabbitMQ, mas aplicado na camada da plataforma e por destination, e não por consumidor.

Casos de uso comuns de event gateways

Event gateways são a escolha certa quando o problema é gerenciar o ciclo de vida dos eventos que atravessam fronteiras de sistemas:

• Gestão de webhooks de entrada: receber webhooks de provedores SaaS em escala — com enfileiramento, verificação de assinatura, deduplicação e lógica de retry resolvidos no nível da plataforma, e não em código customizado da aplicação.
• Entrega de webhooks de saída: oferecer assinaturas de webhook aos seus clientes, com o event gateway cuidando de autenticação, lógica de retry, rate limiting e visibilidade da entrega por você.
• Integração entre sistemas: conectar serviços de terceiros à sua arquitetura interna (ou entre si) recebendo eventos de um sistema, transformando o payload e entregando a outro — sem escrever e manter serviços de cola.
• Endpoints de API assíncronos: aceitar dados de clientes externos, SDKs ou dispositivos via HTTP e canalizá-los de forma confiável para o seu pipeline de processamento.
• Roteamento de eventos serverless: servir como hub central para comunicação orientada a eventos entre funções serverless e serviços que não mantêm conexões persistentes com um message broker.

Para uma comparação lado a lado das plataformas de event gateway, veja o guia comparativo de event gateways.

Principais diferenças entre event gateways e message brokers

Os dois lidam com comunicação assíncrona, mas chegam nela por direções opostas: message brokers são encanamento interno que você embute na sua arquitetura, enquanto event gateways são uma camada gerenciada que cuida do ciclo de vida dos eventos entre fronteiras de sistemas.

Protocolo e modelo de integração

Message brokers falam os próprios protocolos. O Kafka usa um wire protocol binário. O RabbitMQ usa AMQP (ou STOMP, ou MQTT). Produtores e consumidores precisam usar bibliotecas cliente que implementem esses protocolos. Se você precisa aceitar eventos por HTTP — que é como funcionam os webhooks, as APIs externas e a maioria das integrações com terceiros —, você tem que construir uma camada de tradução: um endpoint de API que recebe a requisição HTTP, converte para o formato do broker e publica. Essa camada de tradução, por sua vez, precisa do próprio escalonamento, monitoramento e tratamento de falhas.

Um event gateway é nativo em HTTP. Os eventos chegam por HTTP e são entregues por HTTP. Sem ponte de protocolo, sem bibliotecas cliente para as integrações externas instalarem, sem serviços de tradução customizados para manter. Isso o torna imediatamente compatível com qualquer sistema capaz de enviar ou receber requisições HTTP — ou seja, praticamente todos.

Custo operacional

Rodar um message broker em produção é um compromisso operacional significativo. Uma implantação de Kafka envolve gerenciar brokers, clusters de ZooKeeper ou KRaft, partições de tópicos, fatores de replicação, rebalanceamento de consumer groups, planejamento de capacidade de disco e monitoramento de partições sub-replicadas. O RabbitMQ é mais leve, mas ainda exige gestão de cluster, espelhamento de filas, limiares de alarme de memória e disco e configuração de federação para setups multirregião.

Mesmo serviços gerenciados de broker (Confluent Cloud, Amazon MSK, CloudAMQP) removem apenas a camada de infraestrutura — você continua responsável pelo design dos topics, pela coordenação de consumer groups, pela gestão de schemas, pelo processamento de dead letter queues e pela stack de monitoramento que amarra tudo isso.

Um event gateway é totalmente gerenciado. Você configura sources, destinations, filtros e transformações. A plataforma cuida do escalonamento, da durabilidade, da lógica de retry e da observabilidade. Não há clusters para dimensionar, partições para rebalancear nem consumer groups para coordenar. A superfície operacional é uma ordem de grandeza menor.

Filtragem e transformação

Message brokers roteiam com base na estrutura: em qual topic ou queue a mensagem foi publicada, qual routing key ela carrega (no modelo de exchanges do RabbitMQ) ou qual chave de partição determina seu posicionamento. A filtragem baseada no conteúdo da mensagem — campos do payload, valores de header ou metadados — fica a cargo do código do consumidor. Cada consumidor recebe tudo o que é publicado no seu topic ou queue e decide o que ignorar.

Um event gateway filtra e transforma no nível da plataforma, entre a ingestão e a entrega. As regras avaliam o conteúdo da mensagem, não apenas os metadados de roteamento. Eventos que não atendem aos critérios de filtro de um destination nunca são entregues, o que economiza computação do lado do consumidor. As transformações reestruturam os payloads antes da entrega, de modo que o consumidor recebe os dados no formato que espera. Em uma arquitetura baseada em broker, essa lógica vive em serviços customizados — muitas vezes chamados de serviços de "enriquecimento" ou de "adaptação" — que você escreve, implanta e mantém ao lado do broker.

Modelo de entrega e recuperação de falhas

Tanto brokers quanto event gateways oferecem garantias de entrega, mas os mecanismos são diferentes e otimizados para modos de falha diferentes.

Em um broker, o consumidor puxa as mensagens e é responsável por confirmá-las. Se um consumidor cai, o broker reentrega as mensagens não confirmadas (no RabbitMQ) ou o consumidor retoma a partir do último offset commitado (no Kafka). Dead letter queues capturam mensagens cujo processamento falha repetidamente, mas reprocessá-las exige ferramentas customizadas — scripts para inspecionar a DLQ, descobrir o que deu errado e republicar as mensagens. Não existe um conceito nativo de "reenviar as últimas 6 horas de eventos para este consumidor".

Um event gateway envia os eventos por push para os destinations e assume o resultado da entrega. Se a entrega falha, o gateway faz retry automaticamente segundo uma agenda configurável. Entregas com falha aparecem como issues rastreáveis e com contexto completo — o payload do evento, o destination, a resposta de erro e o histórico de entregas. O replay em massa é uma operação de primeira classe: selecione um intervalo de tempo e reenvie todos os eventos para um destination específico. A recuperação de uma indisponibilidade prolongada é uma ação de configuração, não um projeto de desenvolvimento.

Modelo de observabilidade

Com um message broker, a observabilidade é montada a partir de pedaços. As métricas no nível do broker (consumer lag, throughput por partição, profundidade da fila) vêm da interface de monitoramento do broker ou de exporters como o Prometheus. O tracing no nível da aplicação (quais eventos foram processados, o que continham, o que deu errado) vem dos seus logs de aplicação e ferramentas de tracing. Conectar métricas do broker a resultados da aplicação — "este evento específico de pagamento da Stripe foi consumido 3 vezes e acabou falhando por incompatibilidade de schema" — exige correlação entre vários sistemas.

Um event gateway oferece observabilidade do ciclo de vida como uma visão única e integrada. Cada evento é acompanhado da ingestão à entrega: o que chegou, quais filtros e transformações foram aplicados, para onde foi roteado, quantas tentativas de entrega foram feitas e o status de cada uma. Quando algo falha, você busca o evento e vê o histórico completo em um só lugar, em vez de correlacionar gráficos de consumer lag do broker com logs de erro da aplicação.

Quem é o dono do produtor?

Essa é uma distinção prática que muitas vezes define qual tecnologia é a mais adequada.

Com um message broker, normalmente você é dono dos dois lados: escreve o produtor, escreve o consumidor e controla o schema das mensagens. Isso funciona bem para comunicação interna entre serviços, em que você pode impor um protocolo, garantir schemas e versionar os seus topics.

Com um event gateway, o produtor costuma ser um sistema que você não controla. A Stripe decide quando e como envia eventos de pagamento. A Shopify decide o formato do payload dos seus webhooks. O GitHub decide o esquema de assinatura. Os seus serviços internos não opinam sobre essas decisões. Um event gateway foi feito exatamente para essa assimetria: ele lida com os protocolos heterogêneos, os métodos de verificação, os formatos de payload e os comportamentos de retry de produtores externos para que os seus consumidores internos não precisem lidar com isso.

Comparação de recursos

Exemplos do mundo real

Message broker na prática: um pipeline de pedidos de e-commerce

Considere uma plataforma de e-commerce que processa milhares de pedidos por minuto. Quando um cliente faz um pedido, o serviço de pedidos publica uma mensagem order.created em um topic do Kafka. Cinco serviços internos consomem desse topic de forma independente, cada um no próprio consumer group: reserva de estoque, processamento de pagamento, separação no armazém, notificações por e-mail e um pipeline de analytics que alimenta um dashboard em tempo real.

O log particionado do Kafka faz isso funcionar bem. Cada consumer group lê o stream completo no próprio ritmo. O serviço de pagamento pode ficar temporariamente para trás sem afetar a reserva de estoque. O pipeline de analytics pode reprocessar a última semana de pedidos reiniciando o offset do seu consumidor. A ordenação estrita dentro de cada partição garante que os eventos order.updated de um mesmo pedido sejam sempre processados depois do order.created correspondente.

O time mantém um cluster Kafka com 6 brokers e replicação 3x, monitora o lag dos consumer groups por dashboards do Grafana ligados a um exporter do Prometheus e mantém um dead letter topic com um serviço de reconciliação customizado que inspeciona as mensagens com falha e as republica. A evolução de schemas é tratada por um Confluent Schema Registry que valida schemas Avro na publicação. Essa infraestrutura exige um time de plataforma dedicado para operar, mas dá conta do volume interno de eventos de forma confiável.

Event gateway na prática: as integrações externas da mesma plataforma

Agora considere a camada de integrações externas da mesma plataforma. Ela recebe webhooks de pagamento da Stripe, atualizações de envio da API de um parceiro logístico, eventos de sincronização de estoque do sistema de um fornecedor e notificações de devolução de um portal de trocas de terceiros. Ela também envia webhooks de status de pedido para os lojistas que assinaram esse serviço.

Cada provedor externo tem o próprio formato de payload, esquema de autenticação, comportamento de retry e características de confiabilidade. A API do parceiro logístico às vezes fica fora do ar por 20 minutos durante manutenções. O portal de trocas envia eventos duplicados quando a rede dele está instável. As assinaturas de webhook da Stripe usam um esquema HMAC sensível ao tempo, que exige precisão no relógio do servidor.

Sem um event gateway, o time da plataforma constrói um endpoint HTTP separado para cada provedor, escreve código de verificação de assinatura customizado para cada um, publica os eventos verificados no cluster Kafka por meio de um serviço de tradução e cria monitoramento para detectar quando as integrações externas ficam silenciosas. O serviço de tradução vira um componente de caminho crítico — se ele cair, todos os eventos externos param de fluir. Detecção de duplicatas, normalização de payloads e tratamento de retry específico por provedor vivem todos em código de aplicação, que acumula complexidade com o tempo.

Com um event gateway, cada provedor externo envia eventos para um endpoint gerenciado pelo gateway. O gateway verifica as assinaturas HMAC da Stripe, valida a chave de API do parceiro logístico e trata o handshake de autenticação do portal de trocas — tudo configurado, não codificado. Eventos duplicados vindos do portal de trocas são detectados e suprimidos. Payloads de provedores diferentes são transformados em um formato normalizado antes da entrega. Quando o parceiro logístico cai e para de enviar eventos, o alerta do gateway sinaliza o silêncio. Quando o próprio serviço de processamento da plataforma fica indisponível durante um deploy, os eventos de entrada ficam enfileirados e são entregues automaticamente assim que o serviço se recupera. Os webhooks de saída para os lojistas são entregues com retries configuráveis e rate limiting, com visibilidade completa da entrega, para que o time de suporte consiga responder às perguntas dos lojistas sobre eventos perdidos.

O cluster Kafka continua cuidando da comunicação interna entre serviços. O event gateway cuida de tudo o que cruza a fronteira entre a plataforma e o mundo externo.

Quando você precisa de cada um?

Você precisa de um message broker quando:

A sua arquitetura exige mensageria interna entre serviços com alto throughput, ordenação estrita, coordenação de consumer groups ou replay de eventos baseado em log. Se você está construindo um pipeline de analytics em streaming, distribuindo jobs em background entre pools de workers ou implementando event sourcing, um broker como Kafka ou RabbitMQ é a ferramenta certa. Você controla os dois lados da conversa, pode impor o protocolo e está disposto a investir no custo operacional de rodar ou gerenciar a infraestrutura do broker.

Você precisa de um event gateway quando:

A sua arquitetura recebe, processa ou entrega eventos que cruzam fronteiras de sistemas — em especial por HTTP. Se você recebe webhooks de provedores externos, envia webhooks para os seus clientes, conecta serviços de terceiros ou roteia eventos entre sistemas que não foram projetados para conversar entre si, um event gateway resolve a verificação, a transformação, as garantias de entrega e a observabilidade que de outra forma exigiriam camadas de código customizado em cima de um broker. O produtor costuma ser um sistema que você não controla, o protocolo é HTTP e o custo operacional de rodar a infraestrutura de um broker não se justifica para o caso de uso.

Você precisa dos dois quando:

Muitas arquiteturas em produção usam os dois. O message broker cuida do backbone interno de alto volume — eventos entre serviços, pipelines de streaming, distribuição de tarefas. O event gateway cuida da camada de integração — webhooks de entrada, notificações de saída, roteamento de eventos entre sistemas. Os eventos podem fluir do gateway para o broker (um webhook externo chega, é verificado e normalizado e depois publicado em um topic interno do Kafka) ou do broker para fora, através do gateway (um evento interno dispara um webhook de saída para o endpoint de um cliente).

O erro é tentar fazer um assumir o papel do outro. Enfiar ingestão HTTP, verificação de assinatura, transformação de payload e lógica de retry específica por provedor em um cluster Kafka cria uma camada de integração frágil e feita à mão, que você vai manter indefinidamente. Rodar um broker autogerido para atender algumas dezenas de integrações de webhook, quando um event gateway gerenciado eliminaria completamente o custo operacional, é over-engineering na direção oposta.

Conclusão

Message brokers e event gateways são ambos fundamentais em arquiteturas orientadas a eventos, mas operam em camadas diferentes. Um message broker é encanamento interno — infraestrutura de alto throughput e protocolo nativo para mover mensagens entre serviços que são seus. Um event gateway é uma plataforma de integração — uma camada gerenciada que cuida de todo o ciclo de vida dos eventos na fronteira entre os seus sistemas e o mundo externo.

A linha divisória prática costuma ser a pergunta sobre quem é o dono do produtor. Quando você controla os dois lados e precisa de throughput bruto, garantias de ordenação e semântica de consumer groups, um broker é a ferramenta certa. Quando o produtor é um sistema externo com esquema de autenticação, formato de payload e características de confiabilidade próprios — ou quando você precisa de filtragem, transformação e observabilidade do ciclo de vida sem o peso operacional de rodar infraestrutura de mensageria —, um event gateway é a ferramenta certa.

Se a sua arquitetura tem tanto fluxos internos de eventos quanto integrações externas, provavelmente você precisa dos dois. Para a camada de event gateway, o Hookdeck Event Gateway oferece ingestão, verificação, filtragem, transformação e entrega gerenciadas, com visibilidade ponta a ponta dos eventos. Para uma introdução completa ao conceito, veja O que é um event gateway?. Para considerações de implementação ao combinar um gateway com uma fila de mensagens, veja o nosso guia sobre filas de mensagens para processamento de webhooks.