Skip to content

SO Apps 8: Event Driven Architecture Info Sources

June 14, 2017

Event Driven Architecture (EDA) greatly facilitates building systems that are more readily extensible than most other forms of software architecture.  Nowadays in the cloud era, such extensibility is a valuable characteristic of many service oriented systems. EDA also:

  • Is a highly scalable way of achieving reliable data integration in widely distributed systems (David Chou, below).
  • Supports near-real-time information dissemination and reactive business processes. (David Chou, below).

This article briefly outlines what EDA is, and its primary components. Then it presents a list of links to various info sources I have found to be most helpful in understanding and using EDA.

EDA systems use a message bus through which several services communicate with each other via messaging as the primary integration mechanism.  Keep in mind messaging is an asynchronous form of communication.  A service is an autonomous process with an API that implements a key chunk of specific business functionality in a system.  A message bus is a logically related group of queues and topics shared by several services so they can send messages to one another, plus a message bus API component providing functionality so services can send and receive messages via the queues and topics in the bus.  A message bus is NOT an enterprise service bus (ESB) since it is much, much lighter weight than an ESB.

Since EDA services mainly communicate with each other via messages sent over a message bus, message sender services are called “publishers” and message receiver services are called “subscribers”.  Any one service can typically both publish and subscribe to messages flowing through the message bus.  And multiple services can subscribe to receive the same types of messages, which opens the door to parallel execution.  EDA messages are known as “event messages” or just “events”.  Drawing from David Chou’s below article, plus others, here is a definition of events:

  • Events usually represent the change of state of a system, and/or the change of state of a business process. For example an event may represent the beginning or ending of the execution of a use case in a business process.
  • Events have a unique type (the event type) and name.
  • Events typically have past tense names since they represent things that have already happened.
  • Events have a payload containing just enough data needed by the event’s subscribers to do the work relevant to the purpose of the event, i.e. to do the work required by the change of state represented by the event.

    • For example, an event payload may contain only a key used by the subscriber to do a database query to get all the data it needs to do the required work. Or the payload may contain all data used directly by a subscriber.
    • The event payload’s data is equivalent to the arguments of a remote-procedure-call service operation. The payload is also equivalent to the “EventArgs” of a UI event (e.g. button click) in UI frameworks like WPF.

As mentioned above, one key characteristic of EDA architectures is they result in a software code bases requiring much less work to extend since its services are highly decoupled from each other by the message bus.  In other words, one service does not know about the existence of other services, nor their messaging endpoints, etc.   Thus EDA services are loosely coupled, as opposed to being tightly coupled to each other as often happens in remote-procedure-call architectures.  EDA services using a message bus have the absolute minimal knowledge required for services to communicate with each other.  A service must know only the following to communicate with other services using events via a message bus:

  • A service subscribes to a message bus to receive certain events that are published to the message bus by various unknown services.
  • A service’s API service operations do a specific kind of work for each specific kind of event type it receives. Each event type is often a business domain “unit of work” of some sort.  (See David Chou’s article, below).
  • A service’s API service operations also publish certain events to the message bus when a notable step of its processing is completed, or when the service operation’s entire processing sequence is complete, so that other services can act in response to those events.
  • Whether a sender or receiver, a service must use the proper data contract (aka event payload format) when dealing with a given event.

In EDA architectures only the message bus API component knows the various queue and topic names, the endpoints, and how to map events to an endpoint, and for subscribers how to map the event to invoke the proper service operation of the subscribing service’s API.  As such, the message bus acts as the intermediary between services, decoupling them from each otherThis strong decoupling allows rapid extension of a system’s capabilities – just add new services and new events unique to it, plus make use of existing events as necessary, and update the message bus API component with new endpoints, etc.  With a message bus, services are coupled to each other only through the events and the event payload data format they share in common.  This is very loose coupling that promotes a great deal of independent variation between a system’s services.  Please see Hohpe’s “Programming Without a Call Stack – Event Driven Architectures” below for key details on the great extent of loose coupling EDA provides, plus a few key challenges in EDA worth knowing about as well.  The challenges of EDA require substantial software engineering experience to effectively use it.

Also note that EDA can be used to extend existing non-EDA systems, due to EDA’s excellent support of extensibility.  While this will require retrofitting some existing software components to support messaging, it may be a worthwhile avenue to explore when considering cloud/on-premises hybrid systems.

The following reference links contain more in depth information about Event Driven Architecture:

  1. The “Event Message” on pp 151 – 153 of Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gergor Hohpe and Bobby Woolfe, Copyright 2004 by Pearson Education.  And at
  2. The “Message Bus” on pp 137 – 141 of Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gergor Hohpe and Bobby Woolfe, Copyright 2004 by Pearson Education.  And at
  3. Programming Without a Call Stack — Event-driven Architectures” by Gregor Hohpe at This is an excellent article that focuses upon how EDA changes the programming model and reduces coupling and the consequences of that.
  4. Using Events in Highly Distributed Architectures” by David Chou, October 2008, in Microsoft’s The Architecture Journal. This article provides a great overview of EDA and definition of terms.
  5. Event-Driven Architecture: SOA Through the Looking Glass” by Udi Dahn.  Provides an overview of EDA with  a focus on data consistency.
  6. Event-Driven Data Management for Microservices” by Chris Richardson of NGINX. Good examples of EDA scenarios, especially in regards to data persistence and consistency.
  7. John Mathon’s 3 article series on EDA in his Cloud Ramblings blog is useful — March 31, 2015;  April 1, 2015, April 2, 2015.  The first blog has a great history of EDA and SOA.  John Mathon is the founder of TIBCO and was CEO for a long time.  TIBCO was a key player in EDA tools in the early days and beyond. John knows the area very well.
  8. Message Driven Architecture Explained — Basics” by Mike at Sapiens Works. A succinct summary of the very basics.

I hope you find this information as useful as I did.

George Stevens

Creative Commons License

dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: