What Is an Event-Driven Microservices Architecture?

To unpack the workings of an EDMA, let’s first consider the problem that it tries to solve.

In traditional software architectures, different parts of a system communicate directly with one another, and they often need to wait for responses before they can continue their tasks. This approach creates challenges for modern systems that rely on components to be available and responsive at all times.

Traditional architectures are often unfit for a complex system with a lot of moving pieces, or a system that needs to handle business logic that is distributed among many tasks at the same time. If one part of a system becomes slow or fails, this can cause delays or failures across the system. Adding more components to the system increases complexity and the dependencies among components.

Modern systems patterned on traditional architectures may suffer from issues related to performance, scalability, and the ability to recover from failures.

The figure illustrates a chain of synchronous actions in which each action cannot begin until the previous action is completed. Working through this chain of actions may only take a few seconds. However, any break or delay in the chain at any point might lead to a cascade of failures — crippling the ordering process and ruining the customer experience.

A better approach to this application would be to use an EDMA. Let’s look first at the key concepts of an event-driven architecture (EDA). From there, it will be simple to apply an EDA to the context of microservices.

An event-driven architecture is a software design pattern focused on coordinating different components of a system through asynchronous events. In this pattern, a component triggers an event when it is done with its task. Meanwhile, another component waits for an event to be triggered before starting its task. Across the system, various components — either triggering events or waiting for events to be triggered or both — can work in parallel to move tasks toward completion.

An EDA consists of three primary components:

1. Event producer: A producer is a component that generates events based on certain occurrences or changes in the system. For example, an event may be generated when a user submits an order or when a package is delivered.

2. Event consumer: A consumer is a component that listens for certain events, taking action based on the event data. For example, a notification component may listen for a “package delivered” event and then take action by sending a text message to a customer.

3. Event router: The router is a middleware component that manages the pipeline of events, routing events from producers to appropriate consumers.

In an EDA, a system may have one router that handles countless types of events generated by dozens of producers, appropriately routing each event in the event stream to dozens of consumers. It’s also not uncommon for a consumer to generate new events of its own, making it also a producer. This forms a chain of reactions within the system.

An EDA promotes decoupling and asynchronous events, both of which contribute to making EDA-patterned systems resilient and flexible.

• Decoupling: Components in a system do not communicate with one another directly, but instead exchange information through events. This separation of concerns enables developers to modify or scale individual components without impacting the entire system. With loose coupling of components, you reduce the risk of cascading failures and improve the maintainability of a system.

• Asynchronous events: By using asynchronous events to communicate, components are not locked up and waiting for an immediate response or acknowledgment from other components. This results in a more responsive and efficient system.

Well-known platforms used for facilitating an EDA, also known as message brokers, include Apache Kafka and RabbitMQ, both of which are open source. Major cloud providers also make EDA-related services available, such as EventBridge from Amazon Web Services (AWS) and Pub/Sub from Google (GCP). If your organization chooses to adopt EDA, you’ll find the ecosystem to be rich with resources and support.

A microservices-based application is a software architecture pattern in which an application is composed of small, loosely coupled services. Each service is responsible for a specific business function and exposes API endpoints for others to communicate with it.

This type of modularization means that services can be developed, deployed, and scaled independently. The result is better flexibility and easier maintainability of the overall system.

So then, what does it look like to apply an event-driven architecture to a microservices-based application? In our description of an EDA, we noted how the components in a system may function as event producers or event consumers (or both). Within the context of a microservices-based application, the “components” of an EDA-patterned system are the microservices that make up the application.

With an EDMA, microservices are decoupled from one another, with each microservice focusing on a specific business function while reacting to asynchronous events generated by other microservices.

What would this look like in action? Let’s return to our original example of the ecommerce system.

By taking an EDMA approach, our system is never deadlocked while one microservice waits for another one to complete its task. In fact, we see that several microservices can perform their business functions independently and in parallel, all in response to a single event.

Now that we’ve covered the core technical concepts for an EDMA, let’s move on to consider its benefits.

Many of the benefits of using an event-driven microservices architecture hinge on the decoupling of services and the push-based nature of working with asynchronous events. These benefits include:

• Improved scalability
• Easier maintenance and upgrades
• Faster software development cycles
• System resilience
• Reduced costs

When building an application of decoupled microservices, each microservice can be independently deployed and scaled according to its specific requirements. This means that when the demand for a particular service changes, it can be scaled up or down without affecting other parts of the system; this flexibility in scaling leads to more efficient resource allocation and improved system performance.

By breaking down an application into smaller, more manageable units (microservices), application maintenance and updating are greatly simplified. Individual microservices can be updated or replaced independently without affecting the entire system. This modular approach reduces the risk associated with system-wide updates.

In addition, this encourages better maintainability, as developers can focus on specific services and their individual requirements, rather than needing to be concerned with a complex, monolithic codebase. An EDMA approach yields benefits that span the entire software lifecycle.

With the modularity of microservices, developers can work on different services simultaneously. This parallel development approach enables quicker iteration, allowing new features and improvements to be delivered more rapidly. Also, because microservices are decoupled from one another, this reduces the interdependence and risk of conflicts between components. The result is a smoother workflow and a faster time to market.

Decoupled microservices promote system resilience through fault isolation. In the case of a failure or issue within a specific service, the impact is usually limited to that service. The risk of system-wide failures is greatly reduced.

System resilience also comes through the asynchronous communication of an event-driven pattern. When some microservices in a system are down or experiencing delays, all other microservices will continue to function. This enhances the overall resilience and reliability of the application.

Ultimately, each of those  benefits affects the bottom line. With more granular and optimal scaling from an EDMA, an organization can avoid overprovisioning resources, keeping its infrastructure costs to a minimum. Developers can build more quickly, maintain an application more easily, and apply updates with higher confidence and lower risk. This reduces your operational and maintenance costs. The resilience provided by an EDMA minimizes the risk of downtime or cascading failures, both of which can be costly to an enterprise.

The benefits are clear. So, the natural question that follows is: Is an EDMA right for you?

An EDMA is not a silver bullet pattern that fits all applications and situations. However, the architecture is particularly well-suited for certain scenarios, including for applications that require fanout or parallel processing, for replication of data across accounts or regions, and for systems that require high levels of concurrency or scalability.

In some situations, you may have an application that needs to process multiple tasks concurrently or distribute the aggregate workload across various components for efficient handling. This type of application would benefit from asynchronous communication between services, which would allow them to operate independently and react to events as they occur. An EDMA pattern would fit well here.

In an EDMA, an event can be simultaneously consumed by multiple microservices, each of which can subsequently process the event in parallel. This parallel processing capability allows the system to efficiently handle high volumes of tasks, distribute the workload, and maintain responsiveness even under heavy loads or in the presence of multiple consumers (Figure 3).

Your organization may need to synchronize data across multiple accounts or geographic regions to enhance redundancy, data durability, and availability. By facilitating efficient and asynchronous communication between distributed services, an EDMA-patterned system can propagate a data-change event to services or data stores across accounts or regions.

By taking an asynchronous approach, data replication can be performed consistently but without impacting the performance of the primary application.

In systems that require high levels of concurrency or scalability, an EDMA is an excellent choice because services can operate independently and handle multiple tasks simultaneously. An addition to different services working simultaneously, asynchronous communication allows each service to process events at its own pace. This ensures that the system remains responsive even under heavy workloads or rapidly changing demands.

These three scenarios are not the only ones in which a system designed on the EDMA pattern may be an excellent choice, but they are common to many enterprises. However, those looking to embrace an EDMA should keep their eyes open to the accompanying challenges.

Although an EDMA can bring many benefits to certain scenarios, it is also not without challenges. One of these is data consistency.

One challenge of systems patterned on an EDMA is the preservation of data consistency. Since microservices in an EDMA communicate through events, real-time changes to data or state may not be immediately reflected across all services, leading to temporary inconsistencies.

An important concept in the EDMA pattern is eventual consistency: allowing for a temporary state of inconsistency in the system, with the expectation that all components in that system will eventually converge on a consistent state.

In response, developers must design their services to handle the case of temporary data inconsistency. This includes adopting patterns like Command Query Responsibility Segregation (CQRS). Application designers can also integrate the idea of event sourcing to address the question of application state consistency.

Is your enterprise ready to build applications using an event-driven microservices architecture? Whether you’re a Fortune 500 company or a new startup, you can lean on solutions from Akamai to help you in your journey. Akamai Connected Cloud provides a massively distributed edge computing platform to enterprises that are ready to build microservices for use at the edge.

Akamai EdgeWorkers consists of serverless computing solutions that let you deploy scalable and low-latency microservices at the edge, across a global network of distributed services. Meanwhile, Akamai provides the global infrastructure (virtual private services, load balancing, storage, SQL-based relational databases, NoSQL databases, and more) to power your event-driven applications — to help ensure that your systems are safe, secure, reliable, and fast.

Many cloud-native systems patterned on an EDMA use containerization with Docker or run on Kubernetes for the orchestration of all the moving pieces. For this, you can look to the Linode Kubernetes Engine (LKE).

When facing the complexity or a distributed system patterned on the EDMA, you can take advantage of Akamai cloud computing’s system-level monitoring and Akamai DataStream to establish strong visibility into your system health. As you face challenges related to data consistency or cloud infrastructure, you can look to Linode Professional Services for architect services and optimization expertise.