Reading Time: 7 minutes

What is event-driven architecture and why should enterprises implement it? 

For nearly 20 years, the common standard of APIs on the web has been restricted to synchronous interactions powered by REST APIs. In a world where enterprises in all industries and sectors are impacted by real-time events like fraud detection, workflow notifications, news feeds, stock ticks, and more, relying only on REST APIs or synchronous communications in your tech backbone will only slow you down. Although RESTful interactions remain the mainstay, there is a strong and imminent need for organizations to react in real-time to business events. 

Common problems with synchronous communication include one-way flow of new information, excessive coupling, decreased flexibility to add new services, failures cascading through all the coupled services, and slow response times to customers. 
This image shows some common problems with synchronous communication including limited flexibility, cascading failures and slow response time.

3 reasons you are not able to scale your event-driven efforts

In a HackerNoon article about event-driven APIs published in 2017, it was estimated that by 2020, 50% of the managed APIs will be event-driven. With the rise of IoT and cloud messaging, the number of use cases and event-driven architecture patterns has increased exponentially across all industry verticals; as such that prediction has indeed come to pass. On the other hand, event-driven architectures have existed for decades, promising to deliver powerful, loosely coupled experiences which are highly adaptable and responsive. Unfortunately, the biggest challenges impeding the widespread adoption of event-driven architectures have been three-fold:

  1. Developers lack visibility into existing events, their current use, and details on how to reuse an existing event. 
  2. IT teams lack industry-standard best practices and conventions for defining machine and human-readable event-driven APIs.
  3. Developers need to work with multiple protocols (JMS, MQTT, AMQP, Kafka, etc.), which can be challenging. 
Different parts of the business have different needs when it comes to discovery, governance, and visibility. At the discovery phase, the business team may be asking, “How do I capture this new point of data in real time?” but the IT team may be asking, “What are the channels for customer change events?” At the governance phase, the business team may be asking, “How do I leverage this new technology to improve business?” while the IT team may be asking” How do I consistently manage event infrastructure?” Finally, at the visibility phase, the business team may be asking, “At what time of the day are we seeing web traffic surge?” and the IT team may be asking, “How do I know when unusual events start occurring?”
This image shows the different needs business and IT teams have during discovery, governance, and visibility stages.

Architect your event-driven journey with Anypoint Platform

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

MuleSoft’s customers would be able to solve these fundamental problems and attain enterprise-scale adoption of event-driven architectures with these key capabilities

  • Developers can now design event-driven APIs using AsyncAPI specification — a protocol-agnostic human and machine-readable format — to unlock and expose events in the enterprise.
    • Traditionally, events did not have a single standard documented contract for all developers to understand which is a fundamental tenet of success for REST APIs. In case of events, AsyncAPI specification is a standard way to define asynchronous APIs, much like you can do for REST APIs using OpenAPI or RAML. At its core, it is an API specification. Using this, spec developers across the world can speak a consistent language on what their event-driven service does. AsyncAPI helps address many of the challenges that we talked about in the discovery section earlier like the ability to auto-generate dynamic docs for others to read. Finally, ApsyncAPI is an open source specification with support from many industry leader event-driven players.
This image shows design AsyncAPI specifications in Anypoint API Designer. The text reads, "Well-documented contract on how to interact with services. Discover, reuse, manage, and govern events in the enterprise. Open-source and protocol agnostic allowing interoperability,"
This image shows design AsyncAPI specifications in Anypoint API Designer. 

  • Product managers can democratize access to events by exposing these event-driven APIs in Anypoint Exchange. With this capability, your Anypoint Exchange can now act as a single source of truth for your synchronous (REST) and asynchronous APIs (event-driven). 
    • One of the biggest pain points faced by developers was the inability to fundamentally understand the events already existing in an enterprise. This challenge led to many issues like duplication of events across different use cases and siloed development between different teams. With the ability to view REST and event-driven APIs in Anypoint Exchange, product managers can publish and promote all APIs related to a process from the same place. For example, if a developer searches for the word “orders” in a developer portal they would be able to discover both REST and event-driven APIs that can help build that capability 
With Anypoint Exchange, you can discover your reusable assets easily, explore your event-driven APIs quickly, and acquire the right API with limited support.
This image shows how Anypoint Exchange can help you discover your reusable assets, explore event-driven APIs, and acquire the right API with limited support.

Getting started with event-driven APIs on Anypoint Platform

Ready to enjoy these new features? Get started by signing up for a free trial, downloading Anypoint Studio, or learning more about the release in our MuleSoft documentation. 

Series Navigation3 reasons to accelerate your enterprise event-driven API journey >>