Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Push delivery is a delivery mode in which Event Grid namespaces send events to a destination as soon as they're published, so your applications can react to discrete events without polling. Over HTTP, Event Grid pushes each event to a supported event handler or a custom webhook that you configure.
This article explains how push delivery works in Event Grid namespaces and describes the supported event handlers, so you can decide whether it fits your application.
Namespace topics and subscriptions
Events published to Event Grid namespaces land on a topic, which is a namespace subresource that logically contains all events. With namespace topics, you can create subscriptions with flexible consumption modes to push events to a particular destination or pull events at your pace.
Supported event handlers
Event Grid supports the following event handlers:
Push and pull delivery
Event Grid supports push and pull event delivery using HTTP. With push delivery, you define a destination in an event subscription, a webhook, or an Azure service, to which Event Grid sends events. With pull delivery, subscriber applications connect to Event Grid to consume events. Pull delivery is supported for topics in an Event Grid namespace.
Important
Event Hubs is supported as a destination for subscriptions to namespace topics. In coming releases, Event Grid Namespaces will support all destinations currently available in Event Grid Basic along with additional destinations.
When to use push delivery vs. pull delivery
The following are general guidelines to help you decide when to use pull or push delivery.
Pull delivery
- You need full control as to when to receive events. For example, your application might not be up all the time, not stable enough, or you process data at certain times.
- You need full control over event consumption. For example, a downstream service or layer in your consumer application has a problem that prevents you from processing events. In that case, the pull delivery API allows the consumer app to release an already read event back to the broker so that it can be delivered later.
- You want to use private links when receiving events, which is possible only with the pull delivery, not the push delivery.
- You don't have the ability to expose an endpoint and use push delivery, but you can connect to Event Grid to consume events.
Push delivery
- You want to avoid constant polling to determine that a system state change has occurred. You rather use Event Grid to send events to you at the time state changes happen.
- You have an application that can't make outbound calls. For example, your organization might be concerned about data exfiltration. However, your application can receive events through a public endpoint.