%% date:: [[2022-09-08]], [[2022-09-09]] %% # [[Event-driven architecture]] Event-driven architecture is a model for building an application that relies on an application component responding to a certain stimulus rather than being directly invoked. Event-driven architecture involves event _producers_ and event _consumers_ as separate entities that act independently to disseminate or process information. Event-driven architecture is commonly the type employed by an application made up of microservices. ## Event-driven vs traditional architecture ### Traditional architecture Traditional architecture involves a direct call to a service, and is synchronous. This could be a CRUD request (Create, Read, Update, or Delete a record in a database) or a request to an API endpoint. In this model, the thread that makes a request must wait for the response before it can pick up and send the next request in the queue. [^mandot] ### Event-driven In event-driven architecture, messages are put (published) onto intermediary message brokers, which manage queues of information. Then, other services can watch (subscribe) to the queue and then process any message there. Event-driven architecture is not _necessarily_ asynchronous, but it _can be_, and that is generally held to be one of its main benefits. ## Key features of event-driven architecture ### Producers, brokers, consumers Event-driven architecture consists of components that fall within one of three categories. **Producers** create events or messages, either by processing them or by reacting to other events upstream. **Brokers** are intermediaries that store events as well as manage their flow. **Consumers** are downstream applications that use events. They may also subscribe to topics that are relevant to them. ### [[Asynchronicity]] Asynchronicity is a key feature of event-driven architecture, as it is what enables different parts of a system to respond independently to events. Traditional architecture can be described as synchronous processing architecture, and event-driven architecture can be desceribed as asynchronous processing architecture. ### Events An event is any stimulus, including messages, requests, and actions from an internal or external system. They could also include user-generated interactions. > [!question] Events vs. messages > For practical purposes, "events" are used interchangeably with "messages". However, there is a difference in nuance between the two. Events are things that happen, and don't really connote any notification or command associated with those occurences. Messages do connote a notification or some information transfer. [^adevstory] A key feature of an event or message is that it is *immutable*: once it exists, it cannot be changed. Succeeding events or messages may be created to negate the information in a previous one, but each event is immutable even if the big picture of the information changes. ### Message brokers A message broker is essential for allowing communication between different components; otherwise, if communication is not managed in some way, [[Retry storm]]s could occur. - [[Apache Kafka]] - [site](https://kafka.apache.org/) - [[Google Pub-Sub|Pub/Sub]] - [site](https://cloud.google.com/pubsub) - [[RabbitMQ]] Message brokers must also maintain [[Message queuing]] to record the chronological arrival of requests and pass messages on according to the order. ## Benefits of event-driven architecture ### Decoupled Event-driven architecture is [[Decoupling|loosely coupled]]; [^redhat] the producers of the event are different from the consumers, which means that there is also no dependency between the two. ### Real-time Quicker access to data means that teams can adapt to changes more quickly. ### Better scalability and responsiveness Many event-driven architectures exhibit better performance than their more traditional counterparts. [^fowler] This improvement is due in a large part to the fact that there is no blocking between processes as a process waits for a response. [^mandot] ### Works well with microservices Event-driven architecture keeps microservices loose and decoupled from each other, preventing the formation of a [[Monolith]]. ## Disadvantages of event-driven architecture *Asynchronous processing increases likelihood of collision or error*. Messages may arrive out of order. *Increased complexity*. With potential performance improvements come with increased complexity from using multiple actors on a single request. *Higher data storage requirements*. Data is sometimes duplicated across the entire system as each service processes data independently. [^fowler] *Possiblity for decreased performance*. The introduction of message brokers may cause event-driven architecture to be less performant than their traditional counterparts, as there is an additional step for information to go through. In a way, event-driven architecture often prioritises [[Scalability]] over [[Performance]]. *Increased chance of eventual inconsistency*. Because multiple actors are consuming multiple sources of data, event-driven architecture may lead to eventual inconsistency, in which it becomes difficult to tell the sequence of the events as they can get out of sync. For highly sequential events that rely on chronological order, for example, event-driven architecture may not be the best choice. [^adevstory] ## Types of event-driven architecture models ### Pub/sub Pub/sub stands for publishing/subscription, referring to how the event publisher makes information known for the consumers that subscribe to be notified of any changes. This is also how RSS feeds work. ### Event streaming Event streaming is slightly different in that there is no need for consumers to be subscribed just to be informed on new events; event streaming involves publishing a log that consumers have access to. - event stream processing (like [[Apache Kafka]]) - uses data streaming platform - good at detecting patterns - simple event processing - when an event immediately triggers an action in event consumer - complex event processing - requires an event consumer to process because of the complexity of the events ## Concerns in testing event-driven architecture ### [[Logging]] Logging is essential in event-driven architecture, especially when asynchronous messages are involved. Since messages are not sequentially processed, they can finish processing out of order, so not only is there an added risk of things going wrong, but there is also an added difficulty in troubleshooting an issue. ### [[Distributed tracing]] In addition to logging, distributed tracing is necessary to follow the path of a message through an application for troubleshooting purposes. Messages may pass through several queues before they are completely processed. [^mandot] ### Environmental complexity The distributed nature of event-driven applications may make it more difficult or expensive to set up a test environment, as there are more components that need to be functional to run an end-to-end test. However, this is not a fault of event-driven architecture itself. ### Increased concurrency expectations The performance benefits of event-driven architecture means they are capable of generating massive load to other components that are further downstream. Tens of thousands of requests per second is not an uncommon concurrency for these types of applications, so it's even more important to make sure that downstream servers are capable of handling that amount of requests. ## References [^redhat]: Red Hat. _What is event-driven architecture?_ Accessed in May 2021 from [Red Hat](https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture#:~:text=Event%2Ddriven%20architecture%20is%20a,a%20traditional%20request%2Ddriven%20model). [^fowler]: Fowler, M. (2017). _What do you mean by "event-driven"?_. Retrieved from Source URL: https://martinfowler.com/articles/201701-event-driven.html . [[What Do You Mean by Event-Driven]]. [^mandot]: Mandot, S. (2021). _Testing event-driven application architectures: An asynchronous approach_. Test Rail. Retrieved from https://blog.gurock.com/event-driven-application-architectures/ . [[Testing Event-Driven Application Architectures - An Asynchronous Approach|My highlights]]. [^adevstory]: A Dev' Story. (2021). _What is event driven architecture? (EDA - part 1)_. Retrieved from https://www.youtube.com/watch?v=DQ5Cbt8DQbM .