\u003Cfigcaption> \u003Cem>Modern web challenges\u003C/em> \u003C/figcaption>\u003C/figure>\n\u003C!-- /wp:image -->\n\n\u003C!-- wp:heading -->\n\u003Ch2>Introducing event-driven architecture\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:quote -->\n\u003Cblockquote class=\"wp-block-quote\">\u003Cp>\u003Cstrong>Event-driven architecture\u003C/strong> (\u003Cstrong>EDA\u003C/strong>) is a \u003Ca href=\"https://en.wikipedia.org/wiki/Software_architecture\">software architecture\u003C/a> paradigm promoting the production, detection, consumption of, and reaction to \u003Ca href=\"https://en.wikipedia.org/wiki/Event_(computing)\">\u003Cstrong>events\u003C/strong>\u003C/a>.\u003C/p>\u003Ccite> -Wikipedia \u003C/cite>\u003C/blockquote>\n\u003C!-- /wp:quote -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>In the classic three-tier applications, the core of our system was the data(base). In EDA, the focus is shifted towards the events and how they are flowing through the system. This shift allowed us to completely change the way we design applications tackling the problems mentioned above. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Before actually seeing how EDA does that, let’s see what exactly an event is. An event is an action that triggers either a notification or some kind of change in the state of the application. A light has been switched on (\u003Cem>notification\u003C/em>), the thermostat turned off the heating system (\u003Cem>notification\u003C/em>), a user changed his address (\u003Cem>state change\u003C/em>), or one of your friends changed his phone number (\u003Cem>state change\u003C/em>). All of these are events, but that doesn’t mean we should add them to an event-driven solution. In order for an event to be added, it must be relevant to the business. A user placing a new order is a relevant event for that specific business, but him/her eating pizza for lunch is not.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Which events are relevant to a business might be obvious when you think about them, but some of them might not. Especially those events that occur as a reaction to other events. To discover events that are flowing through the system, use a technique called \u003Ca href=\"https://www.eventstorming.com/\">\u003Cstrong>Event Storming\u003C/strong>\u003C/a>. Bring together the stakeholders on an application (from software engineers to business people and domain experts) and map out all the business processes as specific events. After all the business processes are mapped, the result can be used by engineering teams as requirements to build their applications. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:image -->\n\u003Cfigure class=\"wp-block-image\">\u003Cimg src=\"https://lh3.googleusercontent.com/u30zB5mX_mX_JKYjBcnd260-wXPYGsqCOCnBVdGVfxJXXpMfxbTCVHvx4y7qRIaCPU3NZOvKUDiaStP98e5yk2ddGk15vN5BtKhpuS0s7zV9G9T0gjmKWXTyimxCbGYr0SYihMUA\" alt=\"\"/>\u003Cfigcaption> \u003Cem>Example booking application done using event storming\u003C/em>\u003Cbr> \u003C/figcaption>\u003C/figure>\n\u003C!-- /wp:image -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Having figured out what events are and how they can be identified, let’s have a look over how they can solve the common problems mentioned earlier.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Events flow in a single direction, from a producer to a consumer. Compare this with a REST call. The event producer never expects a response from the consumer, while in a REST call there will always be a response. No response, no need to block the code execution until something else happens. This makes events \u003Cstrong>asynchronous\u003C/strong> by nature, completely eliminating the risk of running through timeouts. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Events happen as the result of an action, so there is no target system; we can’t really say service A triggers events to service B; what we can say is service B is interested in the events produced by service A. But there may be some other parties interested as well, like service C or D. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>So how can we make sure that an event triggered by one system, reaches all the interested services? Most of the time this problem is solved by message brokers. A broker is nothing more than an application that acts as a middle-man between the event generator (the application that created the event) and the event consumer. This way, the applications are nicely decoupled taking care of the \u003Cstrong>Availability\u003C/strong> issue I talked about earlier in the post. If an application is not available momentarily, when it comes back online, it will start consuming events and processing them, catching up with all the events triggered when the application was down.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>What about storage? Can events be stored in a database or will there be something else in place? Events can definitely be stored in databases, but by doing so, they lose their “event” aspect. After an event happens, we cannot change it, so events are immutable. Databases on the other hand… they are mutable, we can actually change data after it has been inserted. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>A better approach to store events is by using \u003Cstrong>\u003Cem>Event Logs\u003C/em>\u003C/strong>. Event logs are nothing more than a \u003Cstrong>centralized\u003C/strong> data store where each event is stored as a sequence of immutable records, also called a log. Imagine the log as a journal, where each new event is appended to the end of the list. We can always recreate the latest state by replaying all the events from log from the beginning until present. \u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The only bit that I haven’t covered yet is scalability. Services built using the event-driven mindset are designed to be deployed in a multi-instance scenario. Since the state itself is stored in the event log, the service itself will be stateless, which allows surgical scaling of any particular service that we want. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The only exception to this pattern are services that have to create \u003Cstrong>materialized views\u003C/strong>. In essence, a materialized view represents the state in a point in time of an event log. This approach is used to query the data more easily. Coming back to our scalability issue, materialized view is nothing more than events aggregated in a table like format, but where do we store these tables? Most often, we see these aggregations performed in memory, which automatically transforms our service into a stateful one. A quick and easy solution is to add a local database to each service that creates materialized views. This way, the state is stored in the database and the service is once again stateless.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:image -->\n\u003Cfigure class=\"wp-block-image\">\u003Cimg src=\"https://lh5.googleusercontent.com/3EOr_QiKuLQl9GsVhym0niSzP7hRbiyqhada7nY2BVHtCHc1hx7rmTMIxTcF4P0OVQW8iyPjWUH8I1MR2ICuQhWFizKGcEKrE3EqN-iV_5hDgluVLC7e-7u96hkftlMEVaVQ6NGa\" alt=\"\"/>\u003Cfigcaption> \u003Cem>Event-driven architecture’s answer to the modern web\u003C/em>\u003Cbr> \u003C/figcaption>\u003C/figure>\n\u003C!-- /wp:image -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Although event-driven architecture has existed for more than 15 years, only recently has it gained massive popularity, and there is a reason for that. Most companies are going through a “d\u003Ca href=\"https://en.wikipedia.org/wiki/Digital_transformation\">igital transformation\u003C/a>” phase, and with that, crazy requirements occur. The complexity of these requirements force engineers to adopt new ways of designing software, ones that incur less coupling between services and lower maintenance overhead. EDA is \u003Cstrong>one\u003C/strong> solution to these problems but it is not the only one. Also, you should not expect that everything can be solved by adopting EDA. Some features may still require good old-fashioned synchronous REST APIs or storing data in a relational database. Check what is best for you and design it appropriately! \u003C/p>\n\u003C!-- /wp:paragraph -->","html","2020-03-16T14:00:00.000Z",{"current":516},"how-event-driven-architecture-solves-modern-web-app-problems",[518,526,528,533,538,541,546],{"_createdAt":519,"_id":520,"_rev":521,"_type":522,"_updatedAt":519,"slug":523,"title":525},"2023-05-23T16:43:21Z","wp-tagcat-bulletin","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":524},"bulletin","Bulletin",{"_createdAt":519,"_id":520,"_rev":521,"_type":522,"_updatedAt":519,"slug":527,"title":525},{"current":524},{"_createdAt":519,"_id":529,"_rev":521,"_type":522,"_updatedAt":519,"slug":530,"title":532},"wp-tagcat-code-for-a-living",{"current":531},"code-for-a-living","Code for a Living",{"_createdAt":519,"_id":534,"_rev":521,"_type":522,"_updatedAt":519,"slug":535,"title":537},"wp-tagcat-event-driven-architectures",{"current":536},"event-driven-architectures","event-driven architectures",{"_createdAt":519,"_id":539,"_rev":521,"_type":522,"_updatedAt":519,"slug":540,"title":288},"wp-tagcat-events",{"current":288},{"_createdAt":519,"_id":542,"_rev":521,"_type":522,"_updatedAt":519,"slug":543,"title":545},"wp-tagcat-stackoverflow",{"current":544},"stackoverflow","Stackoverflow",{"_createdAt":519,"_id":542,"_rev":521,"_type":522,"_updatedAt":519,"slug":547,"title":545},{"current":544},"How event-driven architecture solves modern web app problems",[550,556,562,568],{"_id":551,"publishedAt":552,"slug":553,"sponsored":505,"title":555},"e10457b6-a9f6-4aa9-90f2-d9e04eb77b7c","2025-08-27T04:40:00.000Z",{"_type":10,"current":554},"from-punch-cards-to-prompts-a-history-of-how-software-got-better","From punch cards to prompts: a history of how software got better",{"_id":557,"publishedAt":558,"slug":559,"sponsored":12,"title":561},"65472515-0b62-40d1-8b79-a62bdd2f508a","2025-08-25T16:00:00.000Z",{"_type":10,"current":560},"making-continuous-learning-work-at-work","Making continuous learning work at work",{"_id":563,"publishedAt":564,"slug":565,"sponsored":12,"title":567},"1b0bdf8c-5558-4631-80ca-40cb8e54b571","2025-08-21T14:00:25.054Z",{"_type":10,"current":566},"research-roadmap-update-august-2025","Research roadmap update, August 2025",{"_id":569,"publishedAt":570,"slug":571,"sponsored":12,"title":573},"5ff6f77f-c459-4080-b0fa-4091583af1ac","2025-08-20T14:00:00.000Z",{"_type":10,"current":572},"documents-the-architect-s-programming-language","Documents: The architect’s programming language",{"count":575,"lastTimestamp":576},9,"2023-05-25T09:47:09Z",["Reactive",578],{"$sarticleModal":579},false,["Set"],["ShallowReactive",582],{"sanity-eQxVj9u_y3aAFqaJf-FKsjqRvppSAqp7haxOHmIR1ks":-1,"sanity-comment-wp-post-15393-1756370229801":-1},"/2020/03/16/how-event-driven-architecture-solves-modern-web-app-problems"]