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

Taking a closer look at module integration

As I previously stated, all interactions between the modules are entirely synchronous and communicate via gRPC. With a distributed system such as our modular monolith application, there are two reasons that bounded contexts will need to integrate:

  • They need data that exists in another bounded context
  • They need another bounded context to perform an action

Using external data

When a bounded context needs data belonging to another bounded context, it has three options:

  • Share the database where the data is stored
  • Push the data from the owner to all interested components
  • Pull the data from the owner when it is needed

The first option should be avoided in most situations, especially if changes are being made from more than one location. Rules surrounding invariants may not be implemented correctly or at all in every location.

When you push data out, you will be sending it to a list of known interested...