3 Specifications to Consider When Designing Event-Driven Applications

Make your event-driven applications interoperable and portable with AsyncAPI, CloudEvents, and Serverless Workflow specifications.

Dunith Dhanushka
Mar 21 · 5 min read
Photo by Gene Devine on Unsplash

Event-driven applications are loosely-coupled and distributed in nature, built with multiple self-contained components.

These applications are often blamed for the lack of standardization in the components. For example, two event-driven systems will name their operations and event schemas differently, forcing developers to redo the same things repeatedly.

Three promising specifications are emerging in the event-driven application landscape to provide a common way to do things. They are aiming at making event-driven applications portable and interoperable across multiple cloud environments.

This article explores each of them on a high level.

AsyncAPI specification

Event-driven applications are often criticized for being hard to reason about the code. Their asynchronous, loosely-coupled nature made it difficult to trace the execution flow of an application.

For example, an event producer doesn’t know where the events it is producing would end up. Similarly, event consumer has no idea about who produced the event.

These applications are built and operated as loosely-coupled, independent components. Thus, developers have to bank on the documentation to understand the execution flow. The documentation can be a simple wiki page, calling a senior developer, or nothing at all.

That makes it hard for new developers to pick up the project’s pace in a short time. Also, teams who own different application components are not on the same page most of the time.

The AsyncAPI specification addresses this problem by providing a machine-readable specification to document and describe event-driven applications.

It documents the event producers and consumers of an application along with the events they exchange. That provides a single source of truth for the application in terms of control flow. Apart from that, the specification can be used to generate the implementation code and the validation logic.

The following is an example of an event producer that produces UserSignedUp events.

The Account Service emits UserSignedUp event when a new user signs up.

The specification is currently at version 2.0. There’s a vibrant open-source community behind this initiative providing contributions in language SDKs, code generators, and parsers.

Refer this to understand the AsyncAPI specification with a practical example.

CloudEvents specification


In an event-driven system, the events exchanged across components take different shapes. For example, the naming of events and attributes can be different across components.

The lack of a common way of describing events means developers have to write new event handling logic for each event source. Also, there are no common libraries, tooling, and infrastructure for cross-component event delivery. That reduces the portability and interoperability across systems.

CloudEvents is a specification that standardizes how event publishers describe their events. It aims to simplify event declaration and delivery across services, platforms, and beyond.

In a nutshell, CloudEvents adds meta-data attributes to any given event. For example, a unique ID for the event and the type of the event. The following is a collection of required and optional attributes for a typical CloudEvent.

Also, developers can add their own set of attributes with CloudEvents extensions. Like AsyncAPI, the specification provides language-specific SDKs to read and write CloudEvents.

CloudEvents is an initiative organized by the Serverless Working Group of Cloud Native Computing Foundation. It is a new effort, and it’s still under active development, with version 1.0.1 released recently. But many cloud service providers and open-source projects have already adopted the specification. Google Cloud Eventarc, Azure Event Grid, and Knative Eventing are few notable examples.

Serverless Workflow specification

Workflows have become critical components of Serverless applications today. But workflow implementations tend to describe workflows differently.

That leaves developers no consistent way of modeling their serverless orchestrations. No standard workflow format means no shared libraries, tooling, and infrastructure for modeling serverless workflows across different cloud platforms or containers.

That is where the Serverless Workflow specification steps in. Serverless Workflow is a specification for describing workflows in a standard way. It provides a vendor-neutral and platform-independent markup for orchestrating services on multiple runtimes and cloud/container platforms.

At a very high level, the Serverless Workflow specifies how to document a workflow with a set of state transitions and event formats. The workflow can be specified with JSON or YAML. When defining the structure of events, CloudEvents and Serverless Workflow complements each other.

The following is an example workflow written in JSON. It shows a single Operation state with one action that calls the “greeting” function.

"id": "greeting",
"version": "1.0",
"name": "Greeting Workflow",
"description": "Greet Someone",
"start": "Greet",
"functions": [
"name": "greetingFunction",
"operation": "file://myapis/greetingapis.json#greeting"
"functionRef": {
"refName": "greetingFunction",
"arguments": {
"name": "${ .person.name }"
"actionDataFilter": {
"results": "${ .greeting }"
"end": true

The workflow data input is assumed to be the name of the person to greet:

"person": {
"name": "John"

The results of the action is assumed to be the greeting for the provided persons name:

"greeting": "Welcome to Serverless Workflow, John!"

Which is added to the states data and becomes the workflow data output.

The workflow diagram for the greeting workflow

Serverless Workflow is a new effort, and it’s still under active development as a CNCF Cloud Native Sandbox level project. Its working group consists of several leaders in the business automation industry and enthusiasts in that field.


Both AsyncAPI and Serverless Workflow initiatives standardize the way of describing and documenting event-driven applications as a whole. They reuse CloudEvents to describe the format of the events exchanged.

Even though these specifications are still at the early stages, they pave a path towards portable and interoperable event-driven applications.

When you architect your next event-driven application, consider complying with these standards to make your application more interoperable and maintainable in the future.

Event-driven Utopia

Quality content on building event-driven, asynchronous, cloud-native application architectures.

Event-driven Utopia

EdU is a place where you can find quality content on building event-driven, asynchronous, cloud-native application architectures.

Dunith Dhanushka

Written by

Editor of Event-driven Utopia(eventdrivenutopia.com). Engineer, Writer, Works @ WSO2. Thinks event-driven systems will save the world someday.

Event-driven Utopia

EdU is a place where you can find quality content on building event-driven, asynchronous, cloud-native application architectures.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store