Event-Driven, you are not doing.

The Red Shirts Aren’t Part of the Star Wars Universe

What’s wrong with this image?

In the same way, the redshirts are not in Star Wars; message-driven architecture is not event-driven.

One features a mystical Force, diverse alien species, and planets, and the other focuses on scientific and technological plausibility in a series of political themes.

It is like the difference between the US and the European Union.

Well, you get the picture.

I have come across so many architectures that strive to empower organizations with event-driven but settle only with message-driven ones. So what’s the difference?

Let’s look at the core difference, Event vs Message:

Key Differences:

Message

Message is data (command, a document, or some other kind) sent from the message producer to another system or component. It primarily contains information necessary for the receiving part to process and potentially act upon or point to where to find that data. Here is an example of a message:

{
  "messageType": "InventoryCheckRequest",
  "content": {
    "productId": "12345",
    "quantity": 2
  },
  "sender": "ShoppingCartService",
  "recipient": "InventoryService"
}

A message is expected to want a response back from the recipients.

Event

Events represent state changes that other parts of the system or other systems may be interested in. It signals something has happened.

{
  "eventType": "ItemPurchased",
  "timestamp": "2023-11-30T10:15:30Z",
  "eventId": "SFG234SFG234DGD",
  "content": {
    "itemId": "MobileDevice-123",
    "quantity": "2"
  }
}

Or it could even contain the change of state for better visibility. In the following example, the quantity is changed to 5, and the item is now available online on item-123.

{
  "eventType": "InventoryItemUpdated",
  "timestamp": "2023-11-30T10:15:30Z",
  "itemId": "item-123",
  "changes": {
    "quantity": 5,
    "onlineAvailability": true
  }
}

Communication

In Message-Driven Architecture, when a customer decides to complete a purchase, a message is sent to an inventory system to check if the purchase is possible based on available inventory. We expect a response of either available quantity or a yes/no answer to complete the customer’s purchase command.

In an Event-Driven Architecture, when a state change happens, the signals are not sent to a specific system but broadcast to all active subscribers. What subscribers do with the event is not the concern of the producer.

Conclusion

Although event-driven architecture is a form of message-driven architecture, the rules of writing code and building infrastructure are different.

MDA Provides temporal decoupling. In a message-driven architecture, the sender and receiver do not need to be available at the same time.

EDA also provides a high degree of temporal decoupling. The decoupling is both spatial and logical. The event producer does not know how downstream components, known as subscribers, will react to the events.

The utilization of technology stacks like Event Bus, Queues or Streams would not define your architecture as Event-Driven.

Do you agree?