Book Image

Event-Driven Architecture in Golang

By : Stack
5 (1)
Book Image

Event-Driven Architecture in Golang

5 (1)
By: Stack

Overview of this book

Event-driven architecture in Golang is an approach used to develop applications that shares state changes asynchronously, internally, and externally using messages. EDA applications are better suited at handling situations that need to scale up quickly and the chances of individual component failures are less likely to bring your system crashing down. This is why EDA is a great thing to learn and this book is designed to get you started with the help of step-by-step explanations of essential concepts, practical examples, and more. You’ll begin building event-driven microservices, including patterns to handle data consistency and resiliency. Not only will you learn the patterns behind event-driven microservices but also how to communicate using asynchronous messaging with event streams. You’ll then build an application made of several microservices that communicates using both choreographed and orchestrated messaging. By the end of this book, you’ll be able to build and deploy your own event-driven microservices using asynchronous communication.
Table of Contents (18 chapters)
1
Part 1: Event-Driven Fundamentals
5
Part 2: Components of Event-Driven Architecture
12
Part 3: Production Ready

Application architectures

For an event-driven application, there are a few application architectures that we can choose between. They have their pros and cons, and for green field projects, there is only one recommendation I’d make.

Monolithic architecture

This is an application that is typically built from a single code base and is deployed as a single resource. These kinds of applications have the advantage of being easy to deploy and are relatively simple to manage and operate. Outside of needing to maybe communicate with some third-party APIs, a single user interface and database will be most of the infrastructure concerns. The application shown in Figure 2.14 is easy to scale to handle more users by simply deploying it to more instances that point to the same database:

Figure 2.14 – A monolith application

On the other hand, the larger a monolith grows, the harder it is for teams to develop it efficiently, as the development of new features...