Azure Messaging Models

 All of this is straight from Microsoft Documentation. I am just grouping them for better reference. 

Every time i say, "This is what Microsoft says, and then i validate the theory with a practicle implementation". This time, this article is full of thoery, so this is all about what Microsoft says. I take no credit for this infromation.

What is a message?

In the terminology of distributed applications, messages have the following characteristics:

• A message contains raw data, produced by one component, that will be consumed by another component.
• A message contains the data itself, not just a reference to that data.
• The sending component expects the message content to be processed in a certain way by the destination component. The integrity of the overall system may depend on both sender and receiver doing a specific job.

What is an event?

Events are lighter weight than messages, and are most often used for broadcast communications. The components sending the event are known as publishers, and receivers are known as subscribers.

Events have the following characteristics:

• An event is a lightweight notification that indicates that something happened.
• The event may be sent to multiple receivers, or to none at all.
• Events are often intended to "fan out," or have a large number of subscribers for each publisher.
• The publisher of the event has no expectation about the action a receiving component takes.
• Some events are discrete units and unrelated to other events.
• Some events are part of a related and ordered series.

Use Queue storage if you:

• Need an audit trail of all messages that pass through the queue.
• Expect the queue to exceed 80 GB in size.
• Want to track progress for processing a message inside of the queue.

Use Service Bus topics if you:

• Need multiple receivers to handle each message

Use Service Bus queues if you:

• Need an At-Most-Once delivery guarantee.
• Need a FIFO guarantee.
• Need to group messages into transactions.
• Want to receive messages without polling the queue.
• Need to provide a role-based access model to the queues.
• Need to handle messages larger than 64 KB but less than 256 KB.
• Queue size will not grow larger than 80 GB.
• Want to publish and consume batches of messages.

What is Azure Event Grid?

Azure Event Grid is a fully-managed event routing service running on top of Azure Service Fabric. Event Grid distributes events from different sources, such as Azure Blob storage accounts or Azure Media Services, to different handlers, such as Azure Functions or Webhooks. Event Grid was created to make it easier to build event-based and serverless applications on Azure.

There are several concepts in Azure Event Grid that connect a source to a subscriber:

Events: What happened.

Event sources: Where the event took place.

Topics: The endpoint where publishers send events.

Event subscriptions: The endpoint or built-in mechanism to route events, sometimes to multiple handlers. Subscriptions are also used by handlers to filter incoming events intelligently.

Event handlers: The app or service reacting to the event.

What is Azure Event Hubs?

Event Hubs is an intermediary for the publish-subscribe communication pattern. Unlike Event Grid, however, it is optimized for extremely high throughput, a large number of publishers, security, and resiliency.

Choose Event Hubs if:

• You need to support authenticating a large number of publishers.
• You need to save a stream of events to Data Lake or Blob storage.
• You need aggregation or analytics on your event stream.
• You need reliable messaging or resiliency.

Otherwise, if you need a simple event publish-subscribe infrastructure, with trusted publishers (for instance, your own web server), you should choose Event Grid.

Event Hubs lets you build a big data pipeline capable of processing millions of events per second with low latency. It can handle data from concurrent sources and route it to a variety of stream-processing infrastructures and analytics services. It enables real-time processing and supports repeated replay of stored raw data.