Service-Oriented Architecture vs Event-Driven Architecture

We all want useful and interesting content pushed to us. News alerts appear on our phones, message notifications appear on our desktops. We want to be kept up to date with events, not have to go looking for them. It’s so much easier when the relevant information is delivered to us.

It’s the same with event-driven systems. It’s much more efficient when information appears where it’s needed, rather than a system having to make a call to another system first. By subscribing to a service, event-driven systems know how up-to-date they are, and have accurate information. This is just one advantage of event-driven systems.

In order to know when to use event-driven architectures, we have to understand what the alternatives are, their benefits and drawbacks, and when they are most appropriate. 

What is the difference between event-driven and service-oriented architecture (SOA)?

Service-Oriented Architecture (SOA)

Historically SOA was a response to older isolated software infrastructure, where every domain within a business had its own software specifically for its own purpose, no connection to any other systems, and only served one purpose. SOA allows the separate elements to share information across a business. With SOA as the architecture of your system, the services are the most important aspect.

An important aspect of SOA to remember is that it is an enterprise-wide concept: every part of the software infrastructure needs to be connected, unified by a language. Michael Lebow, when he was IBM Vice President of Web Services, said that SOA “builds highways”. This is a great illustration of what SOA is: a network that connects different services, and the connections to each service can be easily replicated to different services throughout the system.

SOA defines how different components of a system work together. A system built with SOA in mind has a defining language or protocol that unites every part of the system: these can be HTTP, JSON, or other web languages. Each service in the system can communicate with other services in the common language, and the individual services can be monitored or work together through the shared language. This helps unify the siloed languages without compromising their performance. 

It's commonly used in older companies that have not had the opportunity to rethink their architecture in some time. SOA is not a style of architecture that allows for sustainable growth, as it introduces complexity as the business grows. 

Event-Driven Architecture (EDA)

Event-driven architecture sees everything that happens in your system as events and is a ground-up rethinking of the architecture in your business. Making events the foundation of your system enables developers to create a single source of truth within a software architecture that all other systems can rely on. A system that is composed at a fundamental level of event producers and event consumers, each informed by the single source of truth, empowers its users to make better business decisions and be fully informed of all relevant information. It also enables different services to work independently of each other: one producer of events can inform two consumers for different purposes and outcomes, and you can rely on both of the consumers being correct.

With event-driven architecture, it’s the events themselves that are the most important aspect of your system, rather than the services within that system. It keeps your events (the orders placed, the reading measured, the feedback received, etc) as the priority, especially recording what happens to those events. Although SOA makes sure a system's messages are delivered, it can't record them. EDA not only delivers a system's messages, it also prioritizes and provides the context.

Unlike SOA, EDA does not necessarily add more complexity as the business grows. By building a business architecture with events as the foundation, complexity is managed more easily: producers and consumers can be added into the flow of the business events and removed in an efficient manner. With SOA, the first question when adding to the database is "how do I make the defining language interpret this new addition?". With EDA, the "how" is not a concern, the "where" and "what is most efficient" could be the first concern, removing a layer of complication for the development team.

Which to use?

Using SOA or event-driven architecture is going to depend on the needs of your business. SOA is fantastic for companies that are not in a position to rethink their architecture or what they want from their data. If there are siloed applications in your business that require integration, then you may be obliged to use SOA as a step towards a more unified, modern architecture. 

Event-driven architecture is most effective for businesses that want to keep a record of all events and their histories. Many successful businesses in a range of industries have used events as the basis of their system architecture. Using events as the driving force of your architecture enables your businesses to access large data volumes across a wide range of services and stores them in a compact manner. Just imagine what insights you could gain from analyzing all the events that have ever happened in your business...

What is the end goal for your architecture, to serve your existing infrastructure and manage the communication between different applications, or to create a new infrastructure putting business events first and maximizing the use of your data? If you’re still unsure, you can contact our Developer Advocacy team for help deciding what’s best for you.