...
Events - What happened.
An event is the smallest amount of information that fully describes something that happened in the system.
Every event has common information like: source of the event, time the event took place, and unique identifier.
Every event also has specific information that is only relevant to the specific type of event.
An event of size up to 64 KB is covered by General Availability (GA) Service Level Agreement (SLA).
The support for an event of size up to 1 MB is currently in preview. Events over 64 KB are charged in 64-KB increments.
Event sources - Where the event took place.
Your application is the event source for custom events that you define.
Event sources are responsible for sending events to Event Grid.
Topics - The endpoint where publishers send events.
The publisher creates the event grid topic, and decides whether an event source needs one topic or more than one topic.
A topic is used for a collection of related events.
System topics are built-in topics provided by Azure services.
You don't see system topics in your Azure subscription because the publisher owns the topics, but you can subscribe to them.
To subscribe, you provide information about the resource you want to receive events from.
As long as you have access to the resource, you can subscribe to its events.
Custom topics are application and third-party topics.
When you create or are assigned access to a custom topic, you see that custom topic in your subscription.
Event subscriptions - The endpoint or built-in mechanism to route events, sometimes to more than one handler.
Subscriptions are also used by handlers to intelligently filter incoming events.
A subscription tells Event Grid which events on a topic you're interested in receiving.
When creating the subscription, you provide an endpoint for handling the event.
You can filter the events that are sent to the endpoint. You can filter by event type, or subject pattern.
Event handlers - The app or service reacting to the event.
From an Event Grid perspective, an event handler is the place where the event is sent.
The handler takes some further action to process the event.
You can use a supported Azure service or your own webhook as the handler.
Depending on the type of handler, Event Grid follows different mechanisms to guarantee the delivery of the event.
For HTTP webhook event handlers, the event is retried until the handler returns a status code of
200 – OK.For Azure Storage Queue, the events are retried until the Queue service successfully processes the message push into the queue.
You can authenticate clients that publish events to Azure Event Grid topics, domains, partner namespaces using access key or Shared Access Signature (SAS) token.
For more information, see Using access keys or using Shared Access Signatures (SAS).
...
Event schemas
Events consist of a set of four required string properties.
The properties are common to all events from any publisher.
The data object has properties that are specific to each publisher.
Event sources send events to Azure Event Grid in an array, which can have several event objects.
When posting events to an event grid topic, the array can have a total size of up to 1 MB.
Each event in the array is limited to 1 MB.
If an event or the array is greater than the size limits, you receive the response
413 Payload Too Large.Operations are charged in 64 KB increments though.
So, events over 64 KB will incur operations charges as though they were multiple events.
Event Grid sends the events to subscribers in an array that has a single event.
You can find the JSON schema for the Event Grid event and each Azure publisher's data payload in the Event Schema store
Properties that are used by all event publisher
For custom topics, the event publisher determines the data object.
...