Event Driven Architecture – The Basics

Networking in the platform 1 days was a complicated affair and there were few computers that were networked.

How do you share information


I imagined a world where when something changed in one place it would automatically be delivered to all interested parties everywhere virtually instantly.



I called it the information bus and initially when we went to VCs they pretty much laughed at us.  They had no idea there was a market to integrate applications and nobody cared if information was current.  They wouldn’t even hear our presentation which is pretty remarkable because they will generally listen to almost anything.



Managers would typically get information at the end of the month.  It staggers me to think that was considered perfectly okay.  I wonder what their reaction to todays social “checking in” would be.

Fortunately we found an industry that did care if information was current.  Trading floors and stock exchanges needed information as soon as it was available and our event driven technology of publish subscribe became the standard quickly.

trading floor example

Over a short time many businesses discovered that having information just in time was actually very useful for factory floors, for logistical operations and even companies which didn’t seem to be needy of real-time event-driven infrastructure.

Trading Floor Info Bus


As we implemented these event based architectures we discovered common elements that all the systems needed.  Among the first common components was Business Activity monitoring and Mediation.

EDA spurred Middleware


After that, people discovered a need for Business process automation and Complex event processing.   Thus event driven architecture evolved naturally to solve problems in logically orthogonal problem spaces.  Long-running processes used Business Process Servers, shorter processes were best handled in Message Brokers, stateless transactions in Enterprise Service Buses, stateful transactions in Data Services integrated with RDB’s.  Slow changing data was best handled in Registries, fast changing data was best handled in rules engines.   Real-time eventing was best handled in Complex Event Processing Engines and batch eventing in Business Activity Monitors.

EDA components classified

Each of these tools is a best practices for that type of problem and all the tools are generally useful in any organization to reduce complexity and increase robustness.   Using a tool not suited to a problem inevitably leads to complexity and failures or brittleness.  So, most organizations should break problems into pieces and use the appropriate tools.



These event driven technologies made event driven computing scalable and solved thorny problems.  When Ray Dalio, CEO of Bridgewater systems one of the smartest people in the world and a man obsessed with the quality of business processes first saw BPEL BPS based system for creating systematic behavior to business processes and monitor it he was giddy.  Hardcoded point to point systems had dependencies and inconsistent quality between networked components so that changing anything broke other things you never imagined.

spaghetti architecture


Mediation, registries and publish subscribe made the integration points between applications explicit, manageable and consistent quality.  Event Driven Architecture facilitated agility in the long term and in my experience in the short term with a little education.

SOA (Service Oriented Architecture)

Event driven computing evolved into SOA and numerous practices and technologies evolved that made SOA the architectural standard.  Standard components in a standard SOA architecture include message broker which implements a publish/subscribe mechanism of topics and queues.  Topics and queues use the subjects of the publish/subscribe technology I invented to distribute information to interested parties.

Message Broker Spoke

Over time event driven computing has become synonymous with this SOA architecture but if your goal is to provide information to interested parties as fast as possible other approaches have evolved.

HTTP / HTML came up with an alternative path to EDA

In the early days of the internet the http protocol was invented to deliver information.  Originally there was no need for this information to be current.  In fact Google and Yahoo could take 6 months to index your website.   Even today Google doesn’t promise to update its search of your site on any schedule.    I imagined an internet based on publish/subscribe and worked with Cisco to implement a protocol in routers called PGP but it never took off for many reasons.

The http protocol was enhanced and tricks were employed to create the appearance of real-time updating.  Further refinements were made in HTML5 to make bidirectional instant event oriented communication easy and less of a kludge.

The publish / subscribe event oriented architecture did not proliferate over the internet, instead the web services architecture evolved.   However, most recently publish / subscribe has emerged as the dominant protocol for internet of things devices and protocols.



Enterprises continue to implement SOA Event driven architectures as the gold standard for many applications but a web services architecture has evolved alongside it and the two work fine together.  SOA architecture works well for transactional and highly real-time dependent applications.   Web services architecture works well for more user oriented applications where the end consumer is a human operating at human speed.

Event driven architecture is the standard today.  Almost every application or service built today assumes that you can do whatever you want immediately, get instant feedback on the status of your request and interact in real time with the request and anybody involved in the process.   Whether it is ordering products or a taxi, manufacturing, financial processes, chat or messaging everything is event driven today.

WSO2 offers a full suite of open source components for both event driven SOA architectures and web services architectures to implement highly scalable reliable enterprise grade solutions.      It is typical to use both architectures in today’s enterprises.  WSO2 is one of the only vendors that can deliver all components of both architectures.  WSO2 is also open source and built to be enterprise grade throughout.



This EDA Series:

Event Driven Architecture – The Basics

Event Driven Architecture – Internet of Things – What do trading floors and home thermostats have in common?

Event Driven Architecture – Architectural Examples and Use Cases

Event Driven Architecture – Enterprise Concerns:  High Availability / Disaster Recovery / Fault Tolerance / Load Balancing / Transactional Semantics / Performance Design

Other Articles you may find interesting:

MicroServices – Martin Fowler, Netscape, Componentized Composable Platforms and SOA (Service Oriented Architecture)

Publish / Subscribe Event Driven Architecture in the age of Cloud, Mobile, Internet of Things(IoT), Social

ESB Performance Comparison

Enterprise Application Integration

Event Driven Architecture (EDA) Pattern

Understanding ESB Performance & Benchmarking

Understanding Enterprise Application Integration – The Benefits of ESB for EAI



4 thoughts on “Event Driven Architecture – The Basics

Leave a Reply

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

WordPress.com Logo

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

Facebook photo

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

Connecting to %s