Pattern Name: Event-Driven Architecture (EDA) Category: Integration Architecture / Distributed Systems Complexity: Medium to High Stability: High: foundational pattern for modern distributed systems
As organizations decompose monolithic applications and adopt distributed architectures, the question of how components communicate becomes critical. Synchronous, request-response communication (REST APIs, RPC) creates temporal coupling: the caller must wait for the responder, and both must be available simultaneously. In complex systems with many components, this coupling produces cascading failure modes and limits scalability.
Event-driven architecture addresses this by treating state changes as events that are published to a broker and consumed asynchronously by any interested party.
How do you enable loosely coupled communication between distributed system components, where producers of information do not need to know who consumes it, and consumers do not need to be available when information is produced?
In systems where services or applications communicate directly with each other (point-to-point, synchronous), a change to one service’s interface requires coordinating changes across all its consumers. A slow or failing downstream service can block upstream services. Adding a new consumer requires modifying the producer. The system becomes tightly coupled even though it appears distributed.
Introduce an event broker: a durable, scalable messaging infrastructure that accepts events from producers and delivers them to consumers. Producers publish events (“Customer Account Created”, “Order Status Changed”, “Payment Processed”) to a topic or queue on the broker without knowing who will consume them. Consumers subscribe to the topics they care about and process events when they arrive, independently of other consumers and independently of the producer.
Key components:
Event: An immutable record of something that happened: a fact about a state change. Events carry context (what happened, to what entity, when, with what data). Events are named in the past tense.
Event Broker: The infrastructure that receives, stores, routes, and delivers events. Common brokers include Apache Kafka (high-throughput, persistent, replayable), RabbitMQ (flexible routing, lower throughput), Azure Service Bus, AWS EventBridge, and Google Pub/Sub.
Producer: A service or application that emits events when state changes occur. Producers have no knowledge of or dependency on consumers.
Consumer: A service or application that subscribes to event topics and processes events. Consumers can be added or removed without modifying producers.
Event Schema Registry: A catalogue of event schemas (typically Avro or JSON Schema) that producers and consumers agree on. Schema governance is critical: breaking schema changes are the primary source of EDA failures.
Patterns within EDA include: Event Notification (lightweight events that trigger consumers to query for details), Event-Carried State Transfer (events contain full state, consumers need not query), and Event Sourcing (the event log is the system of record).
Element types to use:
Diagram types: ArchiMate Application Layer diagram showing the event topology; sequence diagrams in UML showing event flows for specific business processes; information flow diagrams showing the data carried in key events
MDG considerations: Define «DomainEvent» as a first-class element type in your MDG profile. Events are often the least-governed artefact in EDA implementations: teams create them ad hoc without registering them in a schema registry or the EA repository. Making events a properly stereotyped, required-metadata element type in Sparx EA creates the discipline that prevents event schema proliferation. Required tagged values: schema URI, owning service, domain, version, classification.
Package structure: An Event Catalogue package containing all registered domain events, organized by domain. A Broker Infrastructure package documenting the event broker topology. An Event Flows package with diagrams showing event-driven process flows for key business scenarios.
EA GraphLink and AI integration: Event-driven architectures are notoriously hard to reason about because causality is indirect: an event triggers a chain of downstream effects that are not visible in any single component. EA GraphLink enables AI tools to answer questions that would otherwise require manual tracing: “What events does the Order service produce?”, “Which services consume the Payment Processed event?”, “What is the full event chain triggered by a Customer Registration?”. For impact analysis: “if we change the schema of the Shipment Updated event, what consumers are affected?”: AI-assisted queries over the EA model can reduce analysis time from days to minutes.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.