What is EDA?

- [Instructor] First of all, let's answer the question, what is an event-driven architecture or what are event-driven applications? Event-driven architecture is a software design pattern where events determine the flow of the program. These events could be system generated, user generated, could come from internal sources, or even external systems. In an event-driven architecture, applications are built to react to a variety of events. They are also built to produce a variety of events, they processes events asynchronously, and often time real time. This architectural style contrasts with a traditional request-driven or all procedural programming paradigms that you're used to with say, a REST-driven application. Like you can guess, such applications rely on synchronous processing, whereas event-driven architecture is more asynchronous. The event-driven architecture paradigm is a foundational design of an applications communication of state changes around an asynchronous exchange of messages called events. What does all that mean? You see, our world comprised of events. Events define an action that has occurred. Events can be used to notify that an action has occurred within your application, or that your application has performed an action. Now, this architecture allows applications to be developed as highly distributed, loosely coupled, and fault tolerant components. Now, predominantly this is well known in the microservice architecture that you may be using or you may have been exposed to. Let's say an example of an eventing goal. Here on my screen, I am showing you a simple struct that defines an event that occurred. I call this event the PaymentSuccessful event. Now, this event can be used to inform a shipping and fulfillment application or domain that a payment for a particular order is successful and that the order can be shipped. It can also be used to increment a business analytics counter dashboard, or trigger sending an email to a customer to acknowledge their payments. Now, if you look at this screen from line 5 to 10, you see I have the PaymentID on line 6, which most likely refers to the identifier for the payment that was successful. The OrderID, the identifier for the order for which this payment was successful, the time it occurred, the amount, and then the currency. Now, let's try and understand this better. In an event-driven architecture, you have a couple of components. Firstly, you have an event producer. You have an event consumer. You have event channels. And then you have event processors. You most likely can figure out what these are, but I'll try and explain them in the next couple of slides. Your event producer is an entity that generates events. For example, it could be a microservice that detects a change in data and publishes an event about this change. In the example I gave earlier, the producer can be the payment service that produces an event when a particular payment is successful, when it's failed, or whatever. An example of a producer can be simple goal service that monitors a database for changes and publishes and events to a message broker whenever an update occurs. It's important to note that event producers are responsible for generating events, and these events can range from user actions to system generated events, to even things like IoT devices triggering when particular actions occur. When a user click the button, user submitted form adds an item to his or her checkout, when the database is updated, when it shows a task complete, when someone's at your door, your event producer produces events. Secondly, we have event consumers. Now, event consumers are components that listen to events and react to them. Consumers process this event by performing tasks such as updating the database, creating certain, or deleting an entry in the database. Your consumer could also trigger further actions, either synchronously or asynchronously. Your consumer could perform a hybrid operation, fetching some data synchronously via REST, and then further publishing said data asynchronously. A microservice that subscribes to a specific event type from a message broker and processes them such as updating a cache or sending notification's a good example. Now, in the example I gave earlier about the PaymentSuccessful event, a good example of a consumer will be sending notification service that sends an email to a customer. I have here on the screen a typical example. Now, let's move on. The event channel. The event channel is a pathway through which your events will travel from producers to consumers. Remember that producers and consumers in the event-driven architecture style of development are loosely coupled. So they're not as tightly coupled as they will be in a monolith or in a synchronous application. Now, these channels are typically implemented using message brokers which facilitate asynchronous communication and decoupling of producers and consumers. Now, somewhere around chapter three, chapter four, we will talk more about event brokers and what makes them so powerful. But just bear in mind that they are novel engineering because they provide the necessary infrastructure to ensure that your events get delivered. They route your events to the right consumers. They buffer at the event. They ensure that if the consumer is down, they will store the event until the consumer is up again and then they resend. So they really, really ensure that your application is fault tolerant and reliable. A good common example that you may have heard, or that you may have used, of message brokers are tools like Apache Kafka, NATS, RabbitMQ, Amazon SNS or SQS. They're common choices for implementing event channels, and they're just great. I wanted to just add one more, what I call an event store. An event store is a database that's optimized for storing and querying events. They maintain a log of all the events in a time-ordered sequence, enabling the reconstruction of state changes over time. They also enable the query and analytics of events. Now, I have on my screen a simple example of an event-driven application, or an event-driven architecture here. Again, I have a payment service here that produces an event whenever a payment succeeds or fails. And then I have a notification service that consumes said event from the event channel and uses it to say, send the receipt to a customer, send the accounting service some information, use it to trigger some other action, or increment some counters in the dashboard so parties are aware that the payment was successful, and it does all this asynchronously. At the next video we will be looking more at benefits of using event-driven application. See you.