book

Event-Driven Architecture in Golang

by Michael Stack

November 2022

Intermediate to advanced

384 pages

8h 47m

English

Packt Publishing

Read now

Unlock full access

ContributorsAbout the authorAbout the reviewers
Who this book is forWhat this book coversTo get the most out of this bookDownload the example code filesDownload the color imagesConventions usedGet in touchShare Your ThoughtsDownload a free PDF copy of this book
Technical requirementsAn exchange of factsEvent notificationsEvent-carried state transferEvent sourcingCore componentsWrap-upThe MallBots applicationThe pitchApplication servicesAPI gateway servicesClientsA quick note about hexagonsBenefits of EDAResiliencyAgilityUser experience (UX)Analytics and auditingChallenges of EDAEventual consistencyDual writesDistributed and asynchronous workflowsDebuggabilityGetting it rightSummary
Domain-driven designDDD misconceptionsSo, what is it all about then?How is it useful for EDA?Domain-centric architecturesAn evolving solutionHexagonal architecture appliedTestingA rulebook, not a guidebookShould you use domain-centric architectures?How is it useful for EDA?Command and Query Responsibility SegregationThe problem being solvedApplying CQRSWhen to consider CQRSCQRS and event sourcingTask-based UIApplication architecturesMonolithic architectureMicroservicesRecommendation for green field projectsSummaryFurther reading
Technical requirementsWhat are we building?Finding answers with EventStormingWhat is EventStorming?Big Picture EventStormingDesign-level EventStormingUnderstanding the businessRecording architectural decisionsSummaryFurther reading
Technical requirementsA tour of MallBotsThe responsibilities of the monolithModule code organizationUser interfaceRunning the monolithA focus on event-driven integration and communication patternsTaking a closer look at module integrationUsing external dataCommanding external componentsTypes of eventsDomain eventsEvent sourcing eventsIntegration eventsRefactoring side effects with domain eventsWhat about the modules not using DDD?Summary
Technical requirementsWhat is event sourcing?Understanding the difference between event streaming and event sourcingAdding event sourcing to the monolithBeyond basic eventsAdding the event sourcing packageUsing just enough CQRSA group of stores is called a mallA group of products is called a catalogTaking note of the little thingsConnecting the domain events with the read modelRecapping the CQRS changesAggregate event stream lifetimesTaking periodic snapshots of the event streamUsing snapshotsSummary
Technical requirementsAsynchronous integration with messagesIntegration with notification eventsIntegration with event-carried state transferEventual consistencyMessage-delivery guaranteesIdempotent message deliveryOrdered message deliveryImplementing messaging with NATS JetStreamThe am packageThe jetstream packageMaking the Store Management module asynchronousModifying the monolith configurationUpdating the monolith applicationProviding to the modules the JetStreamContextPublishing messages from the Store Management moduleReceiving messages in the Shopping Baskets moduleVerifying we have good communicationSummary

Technical requirementsRefactoring to asynchronous communicationStore Management state transferCustomer state transferOrder processing state transferPayments state transferDocumenting the asynchronous APIAdding a new order search moduleBuilding read models from multiple sourcesCreating a read model recordSummary
Technical requirementsWhat is a distributed transaction?Why do we need distributed transactions?Comparing various methods of distributed transactionsThe 2PCThe SagaImplementing distributed transactions with SagasAdding support for the Command and Reply messagesAdding an SEC packageConverting the order creation process to use a SagaAdding commands to the saga participantsImplementing the create order saga execution coordinatorSummary
Technical requirementsIdentifying problems faced by distributed applicationsIdentifying problems in synchronous applicationsIdentifying problems in asynchronous applicationsExamining potential ways to address the problemThe singular write solutionExploring transactional boundariesHow the implementation will workThe di packageUpdating the Depot module with dependency containersUsing an Inbox and Outbox for messagesImplementing a messages inboxImplementing a messages outboxSummary
Technical requirementsComing up with a testing strategyUnit testsIntegration testsContract testsEnd-to-end testsTesting the application and domain with unit testsTable-driven testingCreating and using test doubles in our testsTesting dependencies with integration testingIncorporating the dependencies into your testsRunning tests with more complex setupsTesting ProductCacheRepositoryBreaking tests into groupsTesting component interactions with contract testsConsumer expectationsProvider verificationsNot building any silosContract testing with PactREST consumer and provider exampleMessage consumer and provider exampleTesting the application with end-to-end testsRelationship with behavior-driven developmentE2E test organizationMaking executable specifications out of our featuresWhat to test or not testSummary
Technical requirementsTurning the modular monolith into microservicesRefactoring the monolith constructUpdating the composition root of each moduleMaking each module run as a serviceUpdates to the Dockerfile build processesUpdates to the Docker Compose fileAdding a reverse proxy to the compose environmentFixing the gRPC connectionsInstalling the necessary DevOps toolsInstalling every tool into a Docker containerInstalling the tools into your local systemUsing Terraform to configure an AWS environmentPreparing for the deploymentA look at the AWS resources we are deployingDeploying the infrastructureViewing the Kubernetes environmentDeploying the application to AWS with TerraformGetting to know the application resources to be deployedDeploying the applicationTearing down the application and infrastructureSummary
Technical requirementsWhat are monitoring and observability?The three pillars of observabilityHow tracing worksInstrumenting the application with OpenTelemetry and PrometheusAdding distributed tracing to the applicationAdding metrics to the applicationViewing the monitoring dataSummary
Other Books You May EnjoyPackt is searching for authors like youShare Your ThoughtsDownload a free PDF copy of this book

Overview

Dive into the world of event-driven architecture with this hands-on guide, "Event-Driven Architecture in Golang". In this book, you'll explore how to utilize asynchronous messaging and event streams to design robust and scalable microservices using Golang. By implementing concepts like event sourcing and CQRS, you'll gain the skills to architect systems resilient to failure and adaptable to changing requirements.

What this Book will help me do

Master event-driven design patterns like CQRS and event sourcing, and integrate them into your applications.
Efficiently apply asynchronous messaging techniques to enhance system communication and scalability.
Learn techniques to maintain data consistency and optimize system reliability in distributed systems.
Build and deploy an end-to-end application that incorporates event-driven architecture principles.
Monitor and improve the performance of your application using robust observability tools.

Author(s)

Michael Stack is an experienced software architect and author with a deep expertise in Golang and distributed systems. Michael has spent years designing, building, and deploying resilient, scalable systems leveraging event-driven architecture. His clear and considerate writing style makes complex topics accessible and engaging.

Who is it for?

This book is for software architects and senior developers with an intermediate understanding of Golang, who aim to design better architectures for modern distributed systems. If you want to learn practical strategies for event sourcing, CQRS, and asynchronous messaging, this book provides clear guidance. Familiarity with Go concurrency features is required. It's perfect for those looking to enhance their software architecture skills in building resilient systems.