Let’s say we want to use Event Driven Architecture. Are our developers having enough knowledge to successfully deliver that project? I worked with the event for many years; does it mean that I am an expert in it? What should be learned in that area?

In this post, I aim to collect key aspects of EDA that are worth exploring.

Why and How

First of all, it will be nice to have a clear understanding of the reason why that architecture is needed. We also need to know what kind of event-driven architecture is used. Each of these approaches has its own pros and cons, all of them could be your personal shut to the leg.

What

The Second is to understand which data should be in the event. Ways how schema will be evolved and how you will deploy applications to not break communication between them.

Send

Sending events could look like a relatively easy task, but you should ensure consistency and performance. Incorrect implementation could cause the wrong order of events or process stuck in case of failure.

An event could be published as part of the transaction in some applications, but it also could be a separate application that detects data changes in other components. Hence, it’s good to know how it works.

Receive

The Final in that list is consumption. When a system receives events, it generally should solve problems that are introduced by previous decisions: solve partial state, incorrect order, and duplicates. Also, the usage of data could be tricky sometimes we need to use several events from one or many channels. Sometimes, data from that event should be composed.

Commonly, consumers work in many threads, so we need to know how to use locks and avoid data loss.

More details

Here is my mindmap with more subtopics: