Orchestrated Event-Driven Architecture (Mediator)
Orchestrated Event-Driven Architecture (OEDA) or Mediator EDA is a design pattern used in distributed systems to manage and coordinate events between services or components. It uses a central controller, called a mediator, to handle all communication and coordination. The mediator receives events, processes them, and sends them to the right services, ensuring that everything works together smoothly and predictably.
As the name suggests, OEDA can be identified by its characteristics, some of which are unique, while others are shared with Choreography Event-Driven Architecture.
A mediator or orchestrator offers centralized control by managing interactions and serving as a single hub for handling workflows and business rules.
In OEDA, which is event-based architecture, components or services communicate by sending out and receiving events, allowing them to stay independent from each other.
Workflow management is another feature of OEDA. It is handled by a mediator, which organizes and coordinates complex workflows by arranging actions in the correct order across different services.
Scalability, flexibility and resiliency of OEDA that greatly influence design decisions, guarantee that the designed system can handle growth and remain reliable under varying conditions.
In this architectural style, the Mediator is a key component and must be designed carefully and effectively because of its unique and important role in OEDA.
Mediator - The Game Changer
In an Orchestrated Event-Driven Architecture, a central component called the Mediator or Orchestrator is responsible for managing and coordinating how services and components work together efficiently as an ecosystem. Its duties can be divided into three main groups as follows:
The mediator serves as the central controller, deciding how events are handled and which services to use. Regarding being responsible for Event Routing and Workflow Management, it orchestrates the steps required to complete tasks like processing orders in an online store.
As the State Manager, the Mediator monitors the current status of workflows, like checking if a payment has been completed in an e-commerce system. On the other words, it makes sure that any unfinished workflows are either attempted again or properly reversed.
The mediator gathers and records workflow events, creating a detailed log that can be used for debugging and analysis reasons. As the Centralized Monitoring component of OEDA, it serves as the main tool for tracking and monitoring the system's overall performance.
There are different types of mediators, but the three most common and widely used by architects are:
- Frameworks which are tools or platforms used to create specialized mediators and provide a structured foundation and predefined functionalities, allowing developers to avoid building everything from scratch. The most popular frameworks include Python's Flask and Java's Spring Boot.
- Platforms for workflow orchestration, whether commercial or open-source, act as mediators in OEDA systems. Their key strengths include providing a visual interface to design workflow steps and the ability to scale effectively for managing large workflows in distributed systems. AWS Step Functions is a commercial option fully integrated with AWS, while Netflix Conductor is an open-source tool designed for microservices and large-scale workflows.
- Asynchronous Communication Tools are becoming the top choice for mediating messages between services. Normally, they support reliable message delivery with possibility of fault tolerance and flexible message routing mechanism. Leading examples include Apache Kafka, a distributed streaming platform ideal for asynchronous service communication, and RabbitMQ, which is well-known for its reliability and simple architecture.
Take a look at Brokers & Queues, for more information.
OEDA - Strengths & Weaknesses
OEDA, like other architectural styles, has its strengths and weaknesses. Its features and capabilities make it an attractive choice for architects as a solution or part of a solution. However, it also has limitations because no single solution can address every problem.
The main advantages and disadvantages of OEDA largely stem from the broker, as it is the distinctive element of this architectural style. Let's explore its pros and cons.
Efficient Coordination: In complex workflows with many services, the mediator makes everything manageable by handling the logic in one place and orchestrating the workflow efficiently.
Consistency in Operational Execution: The mediator guarantees that business rules are applied consistently across all services, preventing any mismatches that could happen in a completely decentralized system.
Single Point of Failure: As the mediator is a critical component of the ecosystem, if it fails, the entire system may stop working. To avoid this, it is suggested to use redundancy and failover mechanisms.
Implementation Complexity: In general, real business processes are not easily explained in a few steps. Defining these processes in a mediator can become complicated over time.
To get a basic understanding of EDA, check out this article: Event-Driven Architecture.
Use case - Wonderland Bookstore Application
To explain Orchestrated Event-Driven Architecture, I’ve used an e-commerce example called Wonderland Bookstore. It includes only the essential services needed for users to order books online.
The Wonderland Bookstore architecture is a simplified example of an Orchestrated Event-Driven Architecture designed for e-commerce. It demonstrates how a user can order books online using a lightweight setup.
The architects incorporates minimal services to make the architecture easy to understand while showcasing the essential features of such a design. By utilizing modern tools and technologies, the system ensures smooth communication between services and seamless operation.
Technology Stack
The technology stack of OEDA Wonderland Bookstore includes RabbitMQ, which serves as a message broker, enabling reliable and efficient communication between services.
Python Flask, in wonderland Bookstore, acts as both a mediator and orchestrator, handling service coordination and providing a foundation for the backend logic.
The programming language of choice is Python, known for its simplicity and readability. To ensure consistency in deployment and scalability, the system is containerized using Docker and managed with Docker Compose.
Data storage is handled by SQLite, a lightweight database ideal for small-scale applications, making it suitable for this demonstration for inventory service and PostgreSQL and SQL Alchemy for customer service.
Wonderland Bookstore Application Components (Services)
The OEDA Wonderland Bookstore is composed of several key components. It consists of two databases, four services, an API to orchestrate the purchase workflow and a broker. In this section, we provide a brief overview of their roles and responsibilities.
The most important component is Orchestrator or Mediator, which acts as an API. Built using Python Flask, it handles customer purchase requests step by step.
RabbitMQ acts as a message broker. RPC is mainly used, since there is a need for responses from the client. Also, topic and direct exchanges are used to send to the notification and logging components.
The Inventory Service keeps track of available books and updates stock levels as orders are placed.
The Logging Service records system activities, debug messages and errors, creating a record for troubleshooting and monitoring. It receives and logs messages in real time.
Dozzle, a log viewer that displays the application logs stored in CSV format. This also provides minimal monitoring possibility that allows developers troubleshoot issues effectively.
The Customer Service manages user information, such as profiles and order histories. The PostgreSQL database is also defined as standalone service to cover the customer information.
The Notification Service alerts users about their order status, such as confirmations and shipping updates and so on.
Payments are processed securely using the Payment Service, which validates transactions and ensures orders are completed successfully.
Together, these components form a cohesive system that showcases the core principles of orchestrated, event-driven architecture while maintaining simplicity and clarity.
Source Code
To gain a better understanding of this simplified OEDA application (Wonderland Bookstore), take a look at the Source Code in my repository.
Wrapping Up
Orchestrated Event-Driven Architecture offers significant advantages for modern software systems. By decoupling services and enabling asynchronous communication through events, OEDA promotes scalability, fault tolerance, and maintainability. Mediator Event-Driven architectural style allows applications to respond dynamically to high traffic or varying workloads, as each service can scale independently based on its specific needs.
In this article, we explored a simplified e-commerce application using Python, Flask, and RabbitMQ to demonstrate the core principles of an Orchestrated Event-Driven Architecture. This example highlighted how individual services communicate asynchronously through events, enabling a decoupled system.
Components Communication: By using Message broker, services like inventory, logging and payment can independently process events, ensuring flexibility and fault tolerance.
Components Decoupling: With events driving communication between services, changes in one part of the application do not directly affect others, promoting maintainability and resilience
Developer Experience: By integrating Flask with RabbitMQ, developers are able to focus on business logic rather than managing complex synchronous interactions.
Share This Article