DEV Community

pkonopacki
pkonopacki

Posted on

5

Event types chaos in Event Driven Architecture

Introduction

Event-driven architecture is a fast-growing approach in the software industry, where the smallest unit of information, known as an event, takes the central stage. Understanding the purpose of the created event queue or topic is important, and defining an event type can be helpful in achieving that. Among the available sources, one can encounter various names for event types. However, the problem lies in the inconsistency and the fact that authors rarely mention the criteria used to create these types. The purpose of this article is to establish a common approach to event type naming convention.

Why, where and what?

When working with events, we usually want to address the following key questions:

  • why did the event happen? What is the purpose of sending or consuming that event?
  • where did the event occur? Did it happen within the domain relevant to my context?
  • what information doest the event provide? Does it offer the complete context, or will additional database access be required to obtain the desired information?

To answer these questions effectively, I propose a classification of event types based on the following criteria:

  1. Purpose (why)
    1. Information event: This event informs about something relevant that happened within given system. (e.g. a payment was booked). System informing about it does not expect any specific action to happen. Typically, the producer of the event maintains it.
    2. Command event: Unlike an information event, a command event is used to initiate a specific action within the system, like creating a new user. In this case, the maintainer of the event usually will be it's consumer.
  2. Context (where)
    1. Domain event: It reflects a significant change that happened within the domain context. Those events are also often considered private, as they are used only within that domain.
    2. Integration event: This type of event is used when more than one domain should be informed about the changes. The event would be produced within the context of one domain and consumed by the applications outside of that domain.
  3. Payload (what)
    1. State transfer event: This event contains complete information about the state of entity. It does not require the uses of the event to fetch any additional information, so it is easy to work with. However, it may not be optimal if the entity's size is too large.
    2. Delta event: A delta event provides only the changes that have occurred since the last known state. It is efficient when the consumer only needs to know what has changed, rather than processing a full state.
    3. Notification event: This type signals that an event has taken place, but it typically lacks detailed information. It serves as an alert to prompt consumers to take further action if necessary.

event types

It is important to note that an event can use many classifications and in fact it should. This is why I find it important to answer those three questions: why, where and what, before designing an event.

Payment processed example

Every event can be categorised differently based on the chosen classification criteria. Let’s consider a "payment processed" event as an example:

  • Purpose: Since it informs about a completed payment, it can be classified as an information event.
  • Context: This event is relevant within the accounting domain, making it a domain event.
  • Payload: Depending on the architecture, the payload may vary. For this example, if the event provides all necessary details about the payment, it would be categorised as a state transfer event.

Final thoughts

Professionals familiar with Event-Driven Architecture will likely recognise the proposed event types, as this classification does not seek to introduce entirely new concepts. Instead, it aims to provide structure to ideas that are often applied inconsistently. I believe that having in mind the proposed classification, emphasises the intentionality of the design.

Though it might seem like the categorisation introduces additional complexity, I think it actually allows better architectural decisions. By explicitly addressing the why, where and what of events, this approach reduces ambiguity and fosters clearer communication among stakeholders.

I believe that the proposed standardised approach to event classification could provide significant benefits to the software industry and the event-driven architecture community.

Image of Timescale

Timescale – the developer's data platform for modern apps, built on PostgreSQL

Timescale Cloud is PostgreSQL optimized for speed, scale, and performance. Over 3 million IoT, AI, crypto, and dev tool apps are powered by Timescale. Try it free today! No credit card required.

Try free

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

👋 Kindness is contagious

Explore a sea of insights with this enlightening post, highly esteemed within the nurturing DEV Community. Coders of all stripes are invited to participate and contribute to our shared knowledge.

Expressing gratitude with a simple "thank you" can make a big impact. Leave your thanks in the comments!

On DEV, exchanging ideas smooths our way and strengthens our community bonds. Found this useful? A quick note of thanks to the author can mean a lot.

Okay