From "Fundamentals of Software Architecture"
🎧 Listen to Summary
Free 10-min PreviewBroker Topology in Event-Driven Architecture
Key Insight
The broker topology is one of the two primary event-driven architecture configurations, distinguished by the absence of a central event mediator. In this setup, the message flow is distributed across event processor components in a chain-like broadcasting fashion, facilitated by lightweight message brokers like RabbitMQ or ActiveMQ. This topology is particularly effective for scenarios involving relatively simple event processing flows where central event orchestration and coordination are not a primary requirement, typically employing a publish-and-subscribe messaging model for its decoupled, asynchronous 'fire-and-forget' nature.
This topology features four main architectural components: an initiating event, an event broker, an event processor, and a processing event. An initiating event, such as placing an auction bid, starts the entire flow by being sent to an event channel within the broker. Without a mediator, a single event processor accepts this event, performs a specific task, and then asynchronously advertises its action to the rest of the system by creating a processing event. This processing event is then sent back to the event broker for further distribution, allowing other interested event processors to react and continue the chain until no further actions are needed, providing inherent architectural extensibility.
The broker topology offers significant advantages including highly decoupled event processors, high scalability, high responsiveness, high performance, and high fault tolerance, akin to a relay race where runners complete their leg and move on. However, it presents considerable disadvantages such as a lack of control over the overall workflow, making error handling and recoverability complex. If a component like a payment processor fails, other processes may continue without awareness of the issue, and there's no inherent mechanism to restart the business transaction or to guarantee data consistency, as no single component maintains the state of the original business request.
📚 Continue Your Learning Journey — No Payment Required
Access the complete Fundamentals of Software Architecture summary with audio narration, key takeaways, and actionable insights from Mark Richards, Neal Ford.