Organizations today are going into a rapid digital transformation. With MuleSoft’s API Led connectivity approach, the integration strategy of the enterprises is now going towards more reusability with quicker deliverables of projects through discovery, self-service, and reusability. But what if we mix the flavor of Event Driven Architecture also into the Enterprise’s Integration Strategy?

With this blog, we are going to experience how Event Driven Architecture can play a vital role in Organization Integration Strategy and how it can be utilized together with MuleSoft’s API-Led Connectivity Approach. To leverage the Event Driven Architecture, Solace PubSub+, Apache Kafka, Rabbit MQ  can be a good fit into Enterprise Integration Master Plan along with MuleSoft’s Anypoint MQ.

In this blog we will be discussing on leveraging Solace PubSub+ into EDA, Solace PubSub+ is a widely used Event Steaming and the messaging platform which enables intelligent middleware for Event-Driven Applications. It acts as a message broker for message-based communication between producers and consumers which offers Messaging as a Service (MaaS) which can be easily integrated with applications to provide real-time event streaming. Check more about Solace from the Solace Official Documentation

What is an Event Driven Architecture?

As per Solace, Event-driven architecture (EDA) is a software design pattern in which decoupled applications can asynchronously publish and subscribe to events via an event broker (modern messaging-oriented-middleware). Event-driven architecture is a way of building enterprise IT systems that lets information flow between applications, microservices, and connected devices in a real-time manner as events occur throughout your business, instead of periodically polling for updates. Event-driven architecture makes sure that in the occurrence of an event, the relevant information of that event is sent to all the systems which require it. 

Benefits of Event-Driven Architecture:

Flexibility
Agility
Scalability
Loose coupling and Responsiveness

Key Players of Event-Driven architecture:

Event Producer
Event Consumer
Event Transport: Which will have the Message broker that will host Queues, Topics, Exchange messages based on routing.

Event-driven architecture makes sure that in the occurrence of an event, the relevant information of that event is sent to all the systems which require it.

Below Diagram suggests how an Event Driven Architecture Key Players can be used in Retail Domain. Event Producers like Mobile application, POS or an eCom website can produce event and send it to Event Broker. These events are simply filtered and routed in real-time to the services and applications which is consuming.

How can API Led Connectivity and Event-Driven Architecture Work Together?

Definition of API Led Connectivity in MuleSoft’s view is a 3 layered approach where each layer is made up of Experience API, Process API, and System API. API-led connectivity has a limitation on communication patterns because of the three tiers (essentially top to bottom), whereas application components exchanging events while using the Event-Driven approach do not have to adhere to the same communication pattern restrictions.

Applications using Event-Driven Architecture, essentially require a message broker which will exchange events utilizing the same message broker. API Led connectivity and the application network under it are defined by the API-centric assets which are published for self-service consumption. The equivalent for an event-driven architecture would revolve around destination and event types. The applications using the EDA will only depend on the exchanged event types, the defined destinations, and the message broker hosting those destinations. Event-driven APIs will only act as a supplement but will not replace the Restful or Webservice APIs. We will look into the coexistence of both patterns in the next section.

The following things should be considered while using Event Driven APIs leveraging the Event Message Broker:

High Reliability, including slow consumer control, fault tolerance, high availability, and disaster recovery.
High Performance in terms of message throughput, data transfer rates, and latency.
Enterprise-grade security to ensure that your infrastructure and information are protected at all times.
Support for many different transport and protocols
Support for all of the most popular cloud environments, public and private, IaaS and Paas, which combined with support for legacy non-cloud environments offers the only unified solution for hybrid cloud data movement.
It should be made sure that the APIs using Event Brokers, should route the message to the right application or destination.
Publishers just need to know what topic or queue to send an event to, and the event broker takes care of delivery to systems that need it.

To get the best practices of implementing Event Driven Architecture with Apache Kafka, Solace, Rabbit MQ and API Led Connectivity together, Contact us today

Solace PubSub+ is a message broker which supports the above key features making Event Driven APIs more robust. It has an event broker that routes events between systems using the publish-subscribe messaging pattern. All applications connect to the event broker, which is responsible for accepting events from senders and delivering them to all systems subscribed to receive them.

Let’s look into an example of an Order Management System and check how can we leverage API Led Connectivity and an Event-Driven Approach in Order Cancel Flow.

At the experience layer, we have a mobile API and web API which will receive Order Cancel Request from the Source system. In this scenario, the mobile API or Web API will publish to orders queue. We have used Solace Pub-Sub+ as a message broker.

At the process layer, an Event Driven API will consume the messages from the orders queue. This Mule application essentially acts as an event handler and inspects the message’s header and payload and based on the data transformation and business logic required by the system layer this API will transform the message and call the System API.

The event handler will decide which APIs to invoke when an order gets cancelled so the message from the original event gets transmitted to the right backend systems. In this example, only the orders backend system needs to be updated. Hence the event handler application will only invoke the orders system API, which exposes the relevant endpoint for updating or cancelling orders and passes the message in the required format.

With the introduction of eventing. The calling API just needs to care about connecting to the message broker and dumping the event onto a queue or topic. We can also implement custom error handler, alerting and reprocessing mechanism here so incase of any downtime with the backend system or API , the same message from the event handler can be sent back to the original queue for reprocessing or we can implement manual acknowledgement to handle the reprocessing. With this approach , we can save the critical data which can be reprocessed later which will eventually avoid business downtime.

Benefits of using Event-Driven Approach along with API Led Connectivity:

Calling service need not worry whether the message has been received or not by the consumer. The message broker takes care of persisting the message until it is successfully consumed by the consumer service. Thus, increasing the overall reliability & availability.
Overall developer efforts and worker cores/memory utilization are reduced as the complex retry logic, and data persistence is offloaded to the messaging layer.
If there are multiple instances of target or consumer. The message can be redelivered to the next available instance if the first instance is down.
Overall user experience is improved.
Redelivery is a common trait of message brokers. Hence Mule workers can save upon costly CPU required for redelivery/retry implementation within code.
Scalability, Resource utilization, and Reusability

Conclusion:

Event-driven architecture can enhance API-led connectivity. The traditional request-driven model and the event-driven model are complementary. This combination of events and APIs gives rise to more reliable solutions, loosely coupled, scalable, reusable, robust, load-balanced, and fault-tolerant while enhancing the overall user experience. On top of that, you can use messaging queues to ensure zero message loss and increase the reliability and robustness of your IT applications. Architects should consider the adoption of EDA at the very beginning of any new project to make full use of its benefits.

We will be coming be next section of practical implementation of Event Driven Architecture with API Led Connectivity using Apache Kafka and MuleSoft. Stay tuned..

Perficient + MuleSoft 

At Perficient, we excel in tactical MuleSoft implementations by helping you address the full spectrum of challenges with lasting solutions, rather than relying on band-aid fixes. The end result is intelligent, multifunctional assets that reduce costs over time and equip your organization to proactively prepare for future integration demands. 

We’re a Premier MuleSoft partner with more than 15 years of integration expertise across industries including financial services, healthcare, retail, and more. After MuleSoft’s acquisition by Salesforce, our continued innovation in the integration space offers more customized experiences on software developed by MuleSoft. We combine the MuleSoft product suite with our connectivity expertise to provide comprehensive solutions both on-premises and in the cloud. 

Contact us today to learn how we can help you develop an API-led connectivity and Event Driven strategy to solve your organization’s digital transformation challenges.  

References:

https://solace.com/what-is-event-driven-architecture
https://blogs.mulesoft.com/learn-apis/api-led-connectivity/what-is-api-led-connectivity
https://www.mulesoft.com/resources/api/types-of-apis
https://solace.com/blog/publish-subscribe-messaging-pattern/?
https://blogs.mulesoft.com/dev-guides/augment-api-elements-from-event-driven-architecture