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.