Agility with event-driven architecture By David Boyne
Agility with event-driven architecture By David Boyne
Event-driven architectures provide agility to engineering teams and organisations. Let’s dive into more details about how and why.
Evolutionary Architecture
-
Common saying with event-driven architectures, is that producers do not know about consumers, this allows consumers to be disconnected to producers.
-
Without the coupling of producer and consumer, consumers can come and go easily.
-
As business requirements change, we can add or change consumers without impacting producers or other parts of our architecture.
-
Discoverability is important for consumers to know what they can subscribe to, documentation can help here.
Grow engineering teams
-
Using events to communicate between teams/domains is a popular way for engineering teams to scale.
-
Event-driven architectures allow us to remain decoupled, and evolve and adapt teams to meet business requirements/features.
-
Event-driven architectures couple with domain driven design very well. Define boundaries in your organisation and create teams around that. Understand how Conway’s law can impact this.
Connecting external systems
-
Event-driven architectures are not just about the events we raise internally within our business or organisation, but events we can also consume and share with others.
-
Modern applications integrate with external systems all the time, consume events from other applications and process them internally (webhooks common pattern)
-
Expose events to other consumers outside your domain/business, can also provide value.
-
Bi-directional events are powerful, reacting to real-time events, processing them and passing them back to the business that produced them.
Impact isolation
-
Producers are often disconnected from the consumers, if consumers fail then impact is isolated.
-
Event-driven architectures can give availability as components/services are isolated and use events to communicate.
-
When consumers fail you have options to deal with this. Having idempotent consumers help, without them you may run into strange side effects.
Publishing future events
-
Some producers may publish events into the architecture even if no downstream consumers are listening to them.
-
If you know your event is valuable to the organisation, you may want to publish it and have the option to listen in the future.
-
If you use this pattern, maybe consider the costs in doing this, does your broker charge for events published?
Extra Resources
- Flow Architectures - Great book by James Urquhart about how events can and will be used to communicate between organisations.
- Bidirectional events example - Connecting organizations and events, here is an example of how Amazon EventBridge explore bidirectional events with Salesforce. Some interesting patterns here.
- Dive more into domain-driven design with EDA - Event-driven architectures, team topologies, domains? What does it all mean? Here is a visual to help you.
- How does pub/sub work in EDA applications - Want to know more about pub/sub patterns, producing events for downstream consumers with a fan out approach. Resource here to help.
- Conway’s law and EDA - Our system is a reflection of the teams that build it. What does that mean for our EDA solutions? This visual can help.
Explore other visuals
Want to work together?
If you're interested in collaborating, I offer consulting, training, and workshops. I can support you throughout your event-driven architecture journey, from design to implementation. Feel free to reach out to discuss how we can work together, or explore my services on EventCatalog.
Download EDA Visuals
Join over 13,000 others learning EDA and download all the EDA visuals directly to your computer. This document updates everytime a new visual is added so make sure you come back to get the latest.