carloscastilla - Fotolia
Event-driven architecture pros and cons: Is EDA worth it?
Event-driven architecture (EDA) is a double-edged sword of service flexibility and management complexity. Let's take a quick look at the ups and downs of EDA.
Traditional applications with tight coupling between components rely on request-driven messaging processes, where calls for data are made directly from one service to another. However, the distributed nature of microservices-based applications has sparked a need for a different approach to communication: something known as an event-driven architecture.
But, as with any architecture decision, the benefits of EDA come with their own baggage, namely in the form of complexity. In fact, not every microservices project will benefit from a comprehensive EDA, particularly those that are small in scale and complexity, as the management complexity can sometimes outweigh the benefits.
All in all, it's important to understand not only what EDA will help you achieve, but the hidden pitfalls that you'll eventually encounter. Let's examine the pros and cons of this architectural approach.
Benefits of event-driven architecture
EDA brings a whole swath of good things to the enterprise, especially when it comes to service coupling and managing asynchronous transactions. Here are three of EDA's biggest benefits:
- Loose coupling. Services that fire events do not need to contain the logic associated with other services' processes. Also, an event broker will retain all messages until they are read by the target service, enabling asynchronous communication.
- Fault tolerance. Since services are decoupled from each other in an event-driven architecture, faults are isolated to individual services. If a subscribing service fails, it doesn't impact the service that sent the event. Communications are queued in a broker until the subscriber is repaired or replaced.
- Reduced technical debt. Even when operating in the same application, EDA allows individual services to operate and update independently. This reduces inter-service dependencies and technical debt between releases.
Event-driven architecture tools: Apache vs. AWS
When it comes to tooling around with EDA, two common options are AWS' cloud services and Apache Kafka.
AWS offers multiple pub/sub services, such as EventBridge, SNS and SQS. These products are relatively easy to implement and manage, but keep in mind the cost of running AWS services can increase quickly depending on pricing or number of users.
For developers on a tighter budget, Apache Kafka is a good alternative. It's an open source platform, but it's supported by a helpful community of developers. There are also managed Kafka services, similar to Amazon Managed Streaming for Apache Kafka, but these are fairly new. Kafka is renowned for its high-performance message queuing, but it comes with operational complexity.
Pitfalls of EDA
Of course, there are some caveats to keep in mind when considering an event-driven approach. These mainly revolve around management complexity, but some are a little more obscure. Here are a few things that can make EDA tough to work with:
- Duplicated events. Without appropriate planning and alignment, a single event may trigger multiple duplicate messages across different services, creating gaps in communication.
- Naming convention confusion. When handling numerous publishers and subscribers, it's easy to have duplicate names or naming errors, especially across multiple teams that don't regularly communicate.
- Lack of clear workflow order. Each step along a workflow is triggered when a service or broker is alerted to a particular event. If the receiving component isn't properly calibrated to respond to the event, it will create errors and cause cascading workflow issues.
- Error handling and troubleshooting. A typical web-scale application can easily include hundreds of message brokers and services, all which will need to constantly pass and receive events. Event-driven architecture requires a comprehensive set of monitoring tools and practices that provides visibility into the event flow.
