.png){kind=small}
.png){kind=small}
When we work with any architecture, we have some standards. With Event Driven Architecture it is no different. Thereby, we have 3 main patterns, which are: Event Notification, Event Carried State Transfer and Event Source. What about knowing a little more about them?
When we work using Event Notifications, the system will send notifications to other systems about a change that has occurred in its domain, in case any of the systems receiving the notification is interested in learning more about the change, it should go to an interface provided by the provider to capture more information.
We'll still use the example from the previous article (If you haven't read it yet, it's in still time, as it's available at this link), which is a customer's address change, but now, think of me in a hypothetical market case (which may be real; I accept royalties), a sales marketplace will share its customer master data with market partners, including banks. This will be especially useful for updates related to address information as it is easier for me to update my address in a marketplace where I will get the new product I bought, instead of remembering to upgrade the bank. With this example in mind, let us go to our use case using Event Notification.
Customers will change their address, Customer Service Centers will be responsible for updating information in the database and triggering an event notification with the message “Customer 43F31A1 updated data” to their broker, service centers that aim at information from that system will be listening and if, for example, the banking service recognizes the customer and is interested in their updated data, they will make a call to customer service centers such as GET/customers/43F31A1 to retrieve the information and update their data. If the banking service does not know the customers in question, it will simply ignore the message.By using this standard, we have the advantage of low coupling, as we separate the receiver from the sender and as a disadvantage we may have the overhead of the producer, as there may be N systems that are interested in the upgrade and, at the same time, can look for more information about it with the producer.
We will use the Event Carried State Transfer when we have to send the complete information in the message, so processors won´t need to refer to a producer to find out what the changes were.
In our example, customers will change their address and the Customer Service Center will be responsible for updating the information in the database and triggering an event notification, but instead of just saying that customer 43F31A1 has updated the data, it will send the message with full data; as in the case of changing the zip code, the message should be "Customer 43F31A1 has updated zip code to 29580000", and with that, processors will have the complete information to perform their work. The processor can store the information in a local database, so that when performing further processing, it does not need to refer to information with the producer, which, in our case, is the customer service center.
By using this standard, we gain resilience, since processors will be able to function even if the producer is unavailable. We will also reduce latency as we no longer have to go to the producer for more information, and as you may already have noticed, one of the advantages is that we will also no longer overload the producer system, because the message contains all the necessary information.
Cons include information replication, and the fact that the processor must be concerned with data consistency, as it now holds information as well.
We use Event Source when we need to store the changes that occur in the state of a system. With each change, we will store the modification as an event, and, when necessary, it will be possible to rebuild the state of the system with confidence, thus reprocessing events.
As per our example, the customer will change their address and the Customer Service Center will be responsible for updating the information in the database and sending the change of address event, which will be stored together with the changed data, in a repository or data base. If at any time our customer service is deleted, for example, we will have an Event Data Source that will enable us to rebuild it, so it may remain as it used to be.
By using Event Source, we gain the audit. If I wish to know what happened and when it occurred, I can query my repository and find it out. We also profit from being able to debug it, which is a tricky point when we are working with event orientation. If one needs to debug the system, one can point the test environment to the repository and perform all the validations that are required.
As disadvantages we could mention is that Event Source is not yet widely used in the market, which can make it difficult to find materials that address the subject.
Besides, we also have the Event Schema, which concerns what we will store in the repository. Will every event take place or will only the upcoming events occur? We need to properly choose which scheme we will follow when storing the information.
Well, these are 3 of the standards we have in event-oriented architecture. Have you worked with any of them? What was your experience like? Let us know!And stay tuned. Soon we’ll post an article addressing the documentation for asynchronous interfaces, namely AsycAPI.
