Microservice components need to send information between each other; however, traditionally, the sender would wait for a reply from the recipient before continuing. An example would be an application that accepts user input and returns a result.

This behavior can cause blocking as one component depends on another, and the more pieces you have that are responsible for discreet operations, the more they must communicate.

To prevent blocking, two alternate patterns are available – events and messaging. Both mechanisms work at a basic level in the same way – they inform other components, either directly or indirectly, but they don’t wait for a reply.

Events are notifications to other system components that have happened, but they do not contain any data, although they may include a reference. When events are triggered, they don’t expect another component to necessarily do something. It is the job of a consuming component to decide what actions must be taken in response.

A typical example of this scenario is that of an image being uploaded to Blob storage. The upload event is triggered, and an Azure function may be configured to wait for that event. When the event happens, the Azure function reads the newly uploaded image, performs an image resize, and stores the new image back in the storage account. The key is that the event’s sender – the storage account – is not dependent on the Azure function doing anything.

Messaging works slightly differently. With messaging, a component will write data to a queue in a particular format. A consumer will be monitoring that queue, and when an item arrives, it will perform an action with that data and then remove it from the queue. An example is an email service. A user enters text into a box and clicks send, and the user interface component then sends that data to an email queue. A separate email service component then reads the data and acts by sending the email. In this scenario, the user interface does not expect a response to say the message has been sent; it relies on a consumer to process it.

Messaging and events often work together. When a message is written to a queue, the queue may trigger an event to notify a consumer to go and read the queue.

Because the sender doesn’t wait for a response, you often need the consumer to trigger another event or write another message once it has been completed that responds. In the example of a user sending an email, the email service triggering an email sends an event that the user interface is monitoring to update the user of success or failure.

Azure provides a series of components to help with both messaging and events, and for the AZ-304 exam, you must know when to use which component. First, we shall look at two options for triggering events – Azure Event Grid and Azure Event Hubs.