Book Image

Event-Driven Architecture in Golang

By : Michael Stack
5 (1)
Book Image

Event-Driven Architecture in Golang

5 (1)
By: Michael 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)
Part 1: Event-Driven Fundamentals
Part 2: Components of Event-Driven Architecture
Part 3: Production Ready

The MallBots application

We’re going to be building a small application that simulates a retail experience coupled with some futuristic shopping robots. We will be building the backend services that power this application. A high-level view of the components involved is shown here:

Figure 1.8 – High-level view of the MallBots application components

Figure 1.8 – High-level view of the MallBots application components

The pitch

“We have developed incredible robots to save the time of people shopping at the mall. Customers will now have access to a kiosk that would facilitate the selection of items from available stores that customers do not wish to visit. After completing their selections, the customer is free to do other shopping or directly visit the depot and wait for their items to be brought in by robots. The customer may pay when they arrive at the depot or may choose to wait for all items to arrive before doing so. After both are done, the transaction is complete, and the customer takes their items and goes on their merry way.”

Application services

Starting with the four services—Orders, Stores, Payments, and Depot—on the right of Figure 1.8, we have the application services. These will all use events to communicate new states for triggers and notifications and will both publish them and subscribe to them. They will also have GRPC application programming interfaces (APIs) to support the API gateway layer.

API gateway services

The API gateway layer displayed down the center of Figure 1.8 will support a RESTful API for the customer kiosks, a management user interface (UI) with WebSocket subscriptions for the staff to use, and finally, a gRPC streams API for the robots. The API gateways are implemented as a demonstration of the Backend for Frontend (BFF) pattern.

The administrative BFF and the automation API gateways will create subscriptions to application events to allow delivery of state changes to clients. Note that we will not be developing API gateway services in this book.


Finally, on the left of Figure 1.8 are the expected clients, as outlined in more detail here:

  • Customer kiosks, placed near or at mall entrances for ease of use
  • An administrative web application for staff to manage the application data, process customer pickups, and take payment
  • Shopper bot clients that perform autonomous shopping tasks for the busy customers

A quick note about hexagons

You’re going to be seeing a lot of hexagons in the diagrams of this book. The services in Figure 1.8 all have some combinations of synchronous and asynchronous communication or connections, and all are drawn as hexagons, as depicted in the following diagram:

Figure 1.9 – Hexagonal representation of a service

Figure 1.9 – Hexagonal representation of a service

The API gateway and application services are all represented as hexagons with inputs (such as the API and event subscriptions, shown on the left) and the outputs (the database and event publications, on the right). This is a visual presentation of hexagonal architecture, and we will be talking more about that in Chapter 2, Supporting Patterns in Brief.