How to name events in Event Driven Architecture
This article is from vinr Tech team. Try our business solutions for FREE.
Every event in an event driven architecture answers 2 important questions of a reacting system or service,
- What happened? — Verb in past tense
- What is involved? — Noun or Nouns when more constructs are involved
Having this clear understanding about what the event name should contain, let’s dive a little deeper. It is easier to think about the noun first because you clearly know what is involved. Usually it will be an entity in your microservice, or an object/actor/system in your business domain.
If you are dealing with a restaurant business it can be an Order, a Dish, or even a Menu. In a social media app it can be a Post, a Comment, or a Message. When it comes to choosing names, the more abstract you go, the sooner your event driven system will suffer. Simply because filtering generic events will have an impact on performance.
Choose names at a granular level when possible
Imagine you are developing a product which handles registration of Business users and Customers. You will be tempted to use an event name User Registered, because developing Generic stuff is now in our DNA. But if you choose a much granular level naming then you are doing it better. This differentiation makes it easy to channel these two events to 2 different topics in Kafka or any pub-sub system, improving the throughput. BusinessUser Registered and Customer Registered could be the names of these 2 events. This way when a microservice has to send a voucher email for newly registered Customers, it can do so by listening only to Customer Registered events.
If you choose a Generic name we have to filter User Registered events by parsing the message body to find userType, or filter through message header. In both the cases we would have wasted a network call and a few milliseconds of execution time. Also when there is a need for a logic which is common for both the users, we can add 2 listeners calling the same business method. Sending Verification Email is one such use case where we need to send emails for both the users.
When multiple constructs are involved
If there are more than one involved parties in an event then we can add both the names in the event instead of trying to simplify the name. For example, In a Supermarket application we can have an event with name Item Price Discounted which involves 2 entities namely Item and Price. Another example is FoodItem VAT Reduced (I am not going to name it Avocado Price Discounted, that’s insanity!). When a newsletter microservice receives these events it can alert users who are interested in food products that are in discount (When I buy groceries, I always pick the one with a discount tag, even when I don’t want it!).
Choosing the right verb
This is the toughest part of naming an event. You will be flooded with thousand verbs by your eloquent colleagues, but nothing will sound right. Well, for starters,
Do not choose verbs like Created, Updated or Deleted, unless the event is a mere CRUD operation.
Reach to the final layer of action beyond which there is no verb that can define the event. Prefer Customer Registered to Customer Created because registered is much granular and it explains that there is a user involved in this event. ‘Created’ gives us the impression that a Customer record was created in a database; so it can also mean someone created the Customer from a backoffice page.
Also I prefer separating these elements of the event name using a period. FoodItem.VAT.Reduced or Customer.Registered. This helps in writing components with flexible binding, for example a microservice can listen to any event that is related to Customer by filtering Customer.* if all Customer events are pushed to 1 topic.
Hope you liked this article. Please read my other stories about Event Driven Architecture.
