Skip to main content
In this article, we explain the difference between a message and an event, and outline when to use each in your distributed applications. A message comprises the raw data generated by one component intended for consumption by another. Crucially, a message contains the actual data—not just a reference.

​
When to Use a Message

Messages are ideal when your distributed application requires guaranteed, specific processing of the communication. Consider the following scenario: Imagine a user uploads a new picture to your photo-sharing application. The mobile app sends the picture data to a web API hosted in Azure. The web API is expected to store this picture in a database for later access by other users. In this case, messaging is essential. The mobile app sends a message containing the picture data to the web API, which then processes and stores the picture in the database. This ensures the picture data is handled correctly with a clear guarantee on its processing.

​
When to Use an Event

On the other hand, events provide a lightweight communication mechanism, ideal for broadcast purposes. In an event-driven architecture, a publisher sends events that subscribers can receive. If no subscriber is active, the event may simply be dropped without further processing. A helpful analogy is subscribing to marketing emails. When you subscribe, you expect to receive notifications whenever new content is available. However, if no subscribers are present at the time of the event, no email is sent. Although the analogy is not a perfect match, it illustrates that events are broadcast to all potential receivers without ensuring that each event is processed.
The image is a table comparing "Message" and "Event" in terms of definition and usage. It explains that messages contain raw data for guaranteed processing, while events are lightweight, used for broadcasts, and may not be handled if no subscriber is present.
Consider another scenario: an application publishes an event that several components or services can subscribe to. In this setup, if subscribers are actively listening, multiple subscribers may consume the broadcasted event.

​
Deciding Between Message and Event

A straightforward question can help you choose the correct communication approach:
  • Does the sender expect the communication to be processed in a guaranteed manner by the receiver?
    • If yes, use a message.
    • If no, an event is more suitable as it broadcasts information without enforcing specific processing behavior.
For systems requiring strict reliability and order in processing, messages are the preferred choice over events.

​
Designing a Messaging Solution

When designing a messaging solution, it is crucial to assess the specific requirements of your application components. Consider whether your use case calls for guaranteed data processing or a lightweight, broadcast mechanism. By clearly defining these requirements, you can select the solution that best fits your architectural needs.
Ensure you meticulously evaluate your system’s needs before deciding on a messaging strategy. Choosing the wrong model can affect both performance and data integrity.
In summary, choose messages for scenarios requiring the destination component to process data in a predetermined way. Opt for events when data is to be broadcast to multiple potential receivers without strict processing guarantees.

Watch Video