Does your company still work with monolithic architectures, or have you already started adopting decoupled services?
This question has become increasingly relevant as modern applications evolve toward more flexible and scalable models.
Many organizations have migrated (either fully or partially) to distributed architectures, either through microservices or hybrid approaches. This has given rise to a new common need: coordinating multiple components that must communicate efficiently, without blocking each other and without creating rigid dependencies.
This is where event-driven models and asynchrony play an important role.
In this article, we will see how the combination of Event-Driven Architectures (EDA) and asynchronous APIs allows us to build highly responsive and scalable systems capable of processing large volumes of information in real time, reducing the load on services, minimizing latency, and improving the user experience.
What is an Event-Driven Architecture?
In traditional systems, communication is usually synchronous: a service requests information, waits for the response, and then continues with the next operations.
In contrast, in event-driven architecture, applications generate “events,” understood as notifications of status changes. These events are published for other components to consume without the need for explicit queries, allowing for a more agile, decoupled, and efficient flow of information.
You may be interested in: https://chakray.com/apache-apisix-the-high-performance-cloud-native-api-gateway-for-microservice-architectures/
The event-driven architecture value proposition
Event-driven architecture (EDA) provides value that goes beyond asynchronous communication: it redefines how systems react, scale, and integrate. Its most important value proposition is the high level of decoupling it offers.
In an event-driven model, services do not need to know each other in order to collaborate. A component simply emits an event (“something happened”), and any other interested service can react to that event without affecting the producer. This enables several benefits, such as:
- Natural scalability
Events are processed when each service is ready, allowing peak loads to be absorbed without compromising the entire system. - Development agility
Teams can create new consumers without modifying existing services. All they need to do is subscribe to the appropriate event. - Superior resilience
If a service is temporarily down, events can remain in the broker until it is available again, preventing cascading failures. - Continuous business evolution
New capabilities, analytics, automations, and microservices can be added incrementally, leveraging events already generated without the need to redesign the entire architecture. - Improved visibility and traceability
When brokers are combined with tools such as AsyncAPI or API Management, events can be documented, monitored, and governed just like any other digital asset
Event Brokers: Understanding the foundations
The premise of event-driven architecture (EDA) is to allow decoupled applications to publish and subscribe to events asynchronously, thanks to an event agent or channel.
- Producers generate a continuous stream of events.
- Consumers listen to those events and react almost in real time.
- There is no direct connection between producers and consumers.
- An event channel acts as an intermediary.
- That channel (event broker) efficiently transports events between the two.
An event-driven architecture consists of three main parts:
- Event producers
- Event consumers
- Event channels
The latter are often implemented as event brokers or ingestion services (for example, Apache Kafka, RabbitMQ, or other messaging and event streaming platforms).
These three components enable events to be delivered in near real-time, producers to be completely decoupled from consumers, and new consumers to be added without modifying the rest of the system.
Event driven architecture
Below, we go into greater detail about each of these components:
What are Event producers?
They are components that generate events when something relevant occurs in the domain (for example, “order created,” “sensor updated,” or “user registered”). They produce a stream of events and send them to the event channel, without worrying about who will consume them.
What are Event brokers?
They are the intermediate infrastructure (brokers, buses, or ingestion services) that receive events from producers and distribute them to consumers. They can implement different models, such as publish-subscribe or event streaming, handling aspects such as routing, retention, ordering, and delivery of events.
What are Event consumers?
These are the components that subscribe to or read events from the broker or event channel and execute business logic in response to them: from simple processing (triggering a function) to complex analysis of event patterns or real-time stream processing.
Asynchronous APIs: Non-blocking, event-driven
Asynchronous APIs were developed to address a fundamental limitation of the traditional model: the need for the client to wait for the server’s response before continuing. In complex or long-running processes, this approach causes blockages, downtime, and inefficient use of resources.
An asynchronous API changes this dynamic. Instead of keeping the connection active, it allows the client to send a request and continue working while the server processes the operation in the background. When the result is ready, it is delivered via notifications, callbacks, webhooks, or messages published to an event channel.
This way:
- The client initiates the process but does not need to wait.
- The server processes in the background, without blocking resources.
- The result arrives later, through an asynchronous mechanism.
- The system gains fluidity, even under variable loads or long tasks.
They are also often referred to as non-blocking APIs or event-driven APIs.
Async API
You may be interested in: https://chakray.com/decoupled-integration-a-path-to-scalable-flexible-and-resilient-system-architectures/
Main features of an asynchronous API
Its main features include:
- Non-blocking:
The client does not actively wait for the response. It sends the request, continues with other tasks, and processes the response when it arrives (via callback, webhook, queued message, etc.). - Event-driven:
Sometimes explicitly defined as an event-driven API: the API publishes events when something happens (order created, message received, etc.), and consumers react to those events. - Concurrent handling of many requests:
They allow multiple queries to be sent simultaneously and large volumes of connections to be managed without each one consuming a dedicated thread, relying on non-blocking I/O and event loops. - Deferred delivery of results:
- The result may arrive later (seconds or minutes later) via a different channel (webhook, queue, stream), without affecting the main flow of the application.
- Decoupling between producers and consumers:
The producer of an event/response (backend service) and the consumer (client, another microservice) only share the message contract; they do not need to know each other, which is very much in line with event-driven architectures.
Most commonly used protocols and patterns
Asynchronous APIs can implement different mechanisms to send and receive information without blocking clients. This is achieved by combining protocols that support flexible communications with patterns that organize how messages are exchanged within an event-driven architecture:
Common protocols
While a synchronous API forces the client to wait for the response using a single traditional HTTP call, asynchronous APIs allow the request to be separated from the response and rely on protocols that enable continuous communication, events, or deferred notifications.
These protocols (such as WebSockets, SSE, or event-based mechanisms) allow messages to arrive when they are ready. Below are the most commonly used protocols in this type of architecture.
WebSockets and HTTP/2
These protocols are widely used when uninterrupted two-way communication is required. They allow an open connection to be maintained for constant data transmission, which is ideal for real-time applications such as chats or dashboards.
Webhooks
A webhook is simply a “callback” that a server makes to a client URL when an event occurs. It is a very lightweight and efficient mechanism: the client does not need to check the status every few seconds.
Server-Sent Events (SSE)
These allow the server to send continuous updates through a simple HTTP connection. Unlike WebSockets, it only sends data from the server to the client, making it ideal for update feeds.
Event brokers (Kafka, AMQP, MQTT…)
When we talk about truly distributed systems, messaging platforms such as Kafka or RabbitMQ come into play. These systems act as an “intermediary” through which events pass, allowing multiple services to consume them without depending directly on each other.
Recommended patterns
In event-driven architectures, adopting a protocol appropriately is only the beginning. It is also important to choose how messages are organized and how services interact with each other.
Below are some of the most common patterns:
1. Publish / Subscribe (Pub/Sub)
A service publishes an event (“X happened”) on a channel or topic, and one or more services subscribe to process it when they receive it. There is no direct call between producer and consumer, which reduces coupling.
This approach allows a service to publish information for others to use when they want, rather than one service constantly querying another.
2. “Entity,” “Event,” and “Request-Response” topics
Good topic design distinguishes between several categories, such as:
- Entity topics: “the current status of X” — ideal for multiple services to have visibility of an entity’s status.
- Event topics: “X occurred” — events that announce changes or actions in the system.
- Request/response topics: An asynchronous pattern that simulates an API call, where a request message and a response message are sent in different topics.
3. Polling / Callback / Webhook
This approach makes it easy for a service to return immediate confirmation while the process continues in the background.
The result can arrive via a callback or a webhook, when the server notifies that the event has already occurred; or, if it cannot receive incoming calls, the client can periodically check the status via polling.
These mechanisms, also recognized in the AsyncAPI ecosystem, allow long-running tasks to be managed without blocking resources and keep the system more flexible and scalable in an event-driven environment.
You may be interested in: https://chakray.com/7-essential-steps-to-design-a-high-availability-it-infrastructure/
The key combination: Why unite Event Brokers and API Management?
REST API vs Event-Driven API
So far, we have understood that an asynchronous API solves a specific problem: avoiding blocking between request and response, allowing a client to receive the result when it is available.
However, modern architectures need to go further.
In event-driven ecosystems, where multiple services independently produce and consume events, asynchrony is no longer just a communication technique between two actors: it is a complete operating model.
Next, we explore how this convergence manifests itself in practice and why it brings real value.
1. Problem: Asynchronous APIs without comprehensive management
In many cases, organizations begin implementing asynchronous APIs to solve specific problems: long processes, high wait times, timeout limits, or the need to offer better user experiences.
Although these APIs eliminate the blockage between request and response, they often face a common limitation: they operate in isolation, without a management model and without a coordination layer that allows the architecture to scale.
When asynchronous APIs exist without comprehensive management:
- Each team implements its own mechanism (webhooks, queues, polling, callbacks),
- There is no centralized view of who produces or consumes events,
- Flows are not documented uniformly,
- Events remain hidden within individual services,
- And the organization loses visibility, traceability, and operational control.
In this scenario, asynchrony solves the blockage, but not the complex nature of the problem.
This is where event brokers come into play as a natural solution. Incorporating a broker such as Kafka, EventBridge, Event Hubs, or RabbitMQ allows you to:
- Centralize event publishing and consumption.
- Completely decouple producers and consumers.
- Provide resilience and buffering.
- Enable multiple consumers without duplicating logic.
- Structure business flows around events rather than direct calls.
When we combine this model with an API Management layer, the organization also gains:
- Security and access control,
- Standardized documentation (AsyncAPI + OpenAPI),
- Discovery and versioning,
- Centralized monitoring,
- And a single catalog for events and APIs.
In other words:
- Asynchronous APIs solve the blocking issue
- Event brokers solve decoupling and scalability
- API Management solves governance
2. How Event Brokers operate within API Management
Event brokers can become managed execution points for event-based APIs. For example:
Some companies operate in such a way that their brokers act as event API gateways, federating API Gateway capabilities to the world of events: protocol mediation, security, traffic control, and exposure of events as API products.
Events can be modelled as “Event API Products,” versioned, published on a developer portal, and consumed under defined policies.
- Some companies operate in such a way that their brokers act as event API gateways, federating API Gateway capabilities to the world of events: protocol mediation, security, traffic control, and exposure of events as API products.
- Events can be modeled as “Event API Products,” versioned, published on a developer portal, and consumed under defined policies.
3. How to build truly event-driven APIs
In addition to publishing or consuming messages, event-based APIs are defined by contracts that describe channels, messages, and schemas. This makes a difference: events are no longer internal “broker” traffic but become formal interfaces, visible to the organization.
When integrated with API Management, these events are documented, cataloged, and versioned just like a REST API, creating a unified discovery experience.
1. Design messages as contracts
Just as OpenAPI defines methods and schemas for REST APIs, AsyncAPI defines messages, payloads, versions, and validations. This allows events to be consumed reliably, regardless of language or platform.
2. Define channels and responsibilities
An event-driven API must make clear:
- Which channel corresponds to which event
- Who publishes
- Who can subscribe
- And what rules govern that exchange
This makes the broker a backbone and the API the contract that describes it.
3. Document the entire flow
The consumer does not need to know how the backend is implemented: they only need to understand what event indicates what, when it is sent, what fields it contains, and how to react to it. In this way, the API becomes an event interface, not just a message sender
4. Expose events as a product
When events are documented with AsyncAPI and published through API Management, they become part of the organization’s integration catalog. This allows you to:
- Version them
- Make them discoverable
- Apply security
- Manage access
- Monitor their consumption
5. Enable flexible integration
An event-driven API allows each consumer to process events at their own pace, connect or disconnect as needed, and react without blocking the overall flow. This provides elasticity that is impossible with a strictly synchronous API.
In short, building truly event-driven APIs means designing event-based contracts, documenting them as products, and leveraging a broker to completely decouple producers and consumers. It’s about turning events into a formal, governed, and scalable interface.
4. Use case: IoT / Smart City – Intelligent control of public lighting
As an example of the potential of Event-Driven APIs, we can take a tutorial for creating AsyncAPI documentation, which uses a fictional company called Smarty Lighting, a smart public lighting system.
In a modern city, thousands of streetlights function as individual nodes that must react to changing conditions: natural light levels, schedules, presence of people, energy consumption, or possible failures.
Managing this scenario through synchronous calls would be unfeasible, as it would involve constantly consulting each device, saturating the network, and forcing thousands of connections to remain open.
You may be interested in the following success story: https://info.chakray.com/case-study-the-pamplona-community-of-municipalities-chakray
With an event-driven approach, the dynamics change completely:
- Each streetlight becomes an event producer, sending information only when something that needs attention occurs (change in brightness, lamp failure, switching on or off, changes in consumption).
- All these events are published in a messaging broker, using lightweight protocols such as MQTT, optimized for IoT devices.
- Central systems act as consumers, subscribing to relevant events to make decisions, such as adjusting light intensity, activating energy-saving modes, or generating maintenance alerts.
Asynchronous (Event-Driven) API model
This allows you to:
- Integrate thousands of devices without increasing complexity.
- Add new services simply by subscribing to existing events.
- Reuse the same flows for analytics, dashboards, or automation.
- Avoid direct coupling between devices and central systems.
Instead of relying on a rigid request-response model, city lighting functions as an ecosystem that reacts to events as they occur, optimizing energy, maintenance, and service quality.
Conclusion
When systems need to react at the exact moment a change occurs, absorb traffic spikes without degradation, execute long processes without blocking resources, or allow new services to be integrated without affecting existing ones, Event-driven APIs offer complete event ecosystems that enable new business capabilities.
Ready to take your architecture to the next level?
At Chakray, we help organizations adopt and scale event-driven architectures and establish API management models that ensure governance, security, and continuous evolution.
If you are considering modernizing your platform, improving the performance of your integrations, or exploring how asynchrony can transform your business processes, our team can accompany you every step of the way: from strategy to implementation. Contact us today!
Talk to our experts!
Contact our team and discover the cutting-edge technologies that will empower your business.
contact us
