Many organizations undergoing digital transformation have a pressing need to connect their applications, data, and devices. Many times their path to success involves moving to an API-led integration strategy. APIs serve a specific role within an organization’s integration approach. They enable unlocking of data from systems, composing data into processes, or delivering an experience. Event-driven APIs are part of a technology mix helping an organization achieve a competitive advantage with real-time integration. In this blog post, we will discuss how MuleSoft’s Anypoint Platform provides support for event-driven architecture and how it is used together with the API-led connectivity approach.
Dimensions of Events
- Programmatic: Primarily programmatic communication approach in nature, i.e. intended for communication between application components.
- Meaning: An event describes a state change that has occurred in an application component, which acts as the event producer.
- Dynamic nature: An event describes something that has already happened.
- Granularity: An event is typically for one well-defined state change.
- Synchronicity: Events are exchanged asynchronously and therefore the event producer and consumer are decoupled in time.
- Communication path: Events are sent by an event producer to a destination for e.g. queue, topic, message exchange, depending on the messaging paradigm, and are then received by event consumers from that destination.
- Broker: Exchanging events requires a message broker, such as or e.g. Anypoint MQ, Kafka, ActiveMQ, or RabbitMQ.
- Contract: The contract for an event is the combination of destination and event (data) type and can be described by an AsyncAPI definition.
Event-driven architecture and API-led connectivity work together
MuleSoft defines API-led connectivity through the lens of a three-tiered approach. These three layers are made up of experience APIs, process APIs and system APIs.
Although application components exchanging events can be organized similarly, however this is not an inherent part of an event-driven architecture.
API-led connectivity restricts communication patterns according to the three tiers (essentially top to bottom), whereas application components exchanging events do not have to adhere to the same communication pattern restrictions.
An event-driven architecture requires a message broker as an additional component of the technology architecture, with all application components, which exchange events having to agree on the same message broker.
The API-centric assets published for self-service consumption define API-led connectivity in application networks. API implementations typically have well-defined static dependencies on other APIs or backend systems.
Let’s look at a few scenarios that need elements from event-driven architecture.
- Integration with SaaS applications: They heavily depend on approaches from an event-driven architecture to ensure high availability and scalability (e.g. event-driven architecture on the Salesforce Customer 360 Platform).
- Internet of Things: The huge volume of events streamed from devices needs to be accessible in real-time and at scale which makes synchronous request-response APIs alone unreasonable.
- Fault-tolerance: A system is listening for notifications when transactions or orders in an eCommerce system have been canceled or failed.
- Avoid polling: Processing notifications (e.g., an order has been updated), decide what action to take, and route the appropriate response to a backend system instead of constantly polling for changes.
- Legacy systems: They need to process the notifications but suffer from reliability issues.
The example below shows the use of the Kafka connector used for consuming and producing events for dealing with topics (event-driven) while following the API-led connectivity approach.
The benefits of combining event-driven architecture with API-led connectivity
With a combined approach, you can reuse process and system APIs for future use cases without having to rewrite transformation logic and connectivity to backend systems.
On top of that, you can use messaging queues to ensure zero message loss, increase the reliability and robustness of your IT applications.
Another tool can be added to cover the situations where synchronous request-response APIs might not be optimal.
Looking to generate API-driven revenue?
Our 25+ years of integration experience in projects within every sector you can think of, combined with a strong partnership with MuleSoft, enable us to guide your organization through every API-related challenge. Looking for help? Feel free to contact us and we’ll see how we can help each other.
Many organizations undergoing digital transformation have a pressing need to connect their applications, data, and devices. Many times their path to success involves moving to an API-led integration strategy. APIs serve a specific role within an organization’s integration approach. They enable unlocking of data from systems, composing data into processes, or delivering an experience. Event-driven APIs are part of a technology mix helping an organization achieve a competitive advantage with real-time integration. In this blog post, we will discuss how MuleSoft’s Anypoint Platform provides support for event-driven architecture and how it is used together with the API-led connectivity approach.
Dimensions of Events
- Programmatic: Primarily programmatic communication approach in nature, i.e. intended for communication between application components.
- Meaning: An event describes a state change that has occurred in an application component, which acts as the event producer.
- Dynamic nature: An event describes something that has already happened.
- Granularity: An event is typically for one well-defined state change.
- Synchronicity: Events are exchanged asynchronously and therefore the event producer and consumer are decoupled in time.
- Communication path: Events are sent by an event producer to a destination for e.g. queue, topic, message exchange, depending on the messaging paradigm, and are then received by event consumers from that destination.
- Broker: Exchanging events requires a message broker, such as or e.g. Anypoint MQ, Kafka, ActiveMQ, or RabbitMQ.
- Contract: The contract for an event is the combination of destination and event (data) type and can be described by an AsyncAPI definition.
Event-driven architecture and API-led connectivity work together
MuleSoft defines API-led connectivity through the lens of a three-tiered approach. These three layers are made up of experience APIs, process APIs and system APIs.
Although application components exchanging events can be organized similarly, however this is not an inherent part of an event-driven architecture.
API-led connectivity restricts communication patterns according to the three tiers (essentially top to bottom), whereas application components exchanging events do not have to adhere to the same communication pattern restrictions.
An event-driven architecture requires a message broker as an additional component of the technology architecture, with all application components, which exchange events having to agree on the same message broker.
The API-centric assets published for self-service consumption define API-led connectivity in application networks. API implementations typically have well-defined static dependencies on other APIs or backend systems.
Let’s look at a few scenarios that need elements from event-driven architecture.
- Integration with SaaS applications: They heavily depend on approaches from an event-driven architecture to ensure high availability and scalability (e.g. event-driven architecture on the Salesforce Customer 360 Platform).
- Internet of Things: The huge volume of events streamed from devices needs to be accessible in real-time and at scale which makes synchronous request-response APIs alone unreasonable.
- Fault-tolerance: A system is listening for notifications when transactions or orders in an eCommerce system have been canceled or failed.
- Avoid polling: Processing notifications (e.g., an order has been updated), decide what action to take, and route the appropriate response to a backend system instead of constantly polling for changes.
- Legacy systems: They need to process the notifications but suffer from reliability issues.
The example below shows the use of the Kafka connector used for consuming and producing events for dealing with topics (event-driven) while following the API-led connectivity approach.
The benefits of combining event-driven architecture with API-led connectivity
With a combined approach, you can reuse process and system APIs for future use cases without having to rewrite transformation logic and connectivity to backend systems.
On top of that, you can use messaging queues to ensure zero message loss, increase the reliability and robustness of your IT applications.
Another tool can be added to cover the situations where synchronous request-response APIs might not be optimal.
Looking to generate API-driven revenue?
Our 25+ years of integration experience in projects within every sector you can think of, combined with a strong partnership with MuleSoft, enable us to guide your organization through every API-related challenge. Looking for help? Feel free to contact us and we’ll see how we can help each other.