> For the complete documentation index, see [llms.txt](https://adidas.gitbook.io/api-guidelines/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://adidas.gitbook.io/api-guidelines/asynchronous-api-guidelines/core-asynchronous-principles/b_basic_concepts_edas.md).

# Event Driven Architectures

Event-Driven Architectures (EDAs) are a paradigm that promotes the production, consumption and reaction to events.

This architectural pattern may be applied by the design and implementation of applications and systems that transmit events amongst loosely coupled software components and services.

An event-driven system typically consists of event emitters (or agents), event consumers (or sinks), and event channels.

* Producers (or publishers) are responsible for detecting, gathering and transferring events
  * Are not aware of consumers
  * Are not aware of how the events are consumed
* Consumers (or subscribers) react to the events as soon as they are produced
  * The reaction can be self-contained or it can be a composition of processes or components
* Event channels are conduits in which events are transmitted from emitters to consumers

**Note** Producer and Consumer role is not exclusive. In other words, the same client or application can be producer and consumer at the same time.

In most cases, EDAs are broker-centric, as seen in the diagram below.

![EDA overview](/files/trwjJ3CkqUbzPZdkLnpb)

*The figure above was taken from AsyncAPI official documentation*

#### Problem statement

Typically, the architectural landscape of a big company grows in complexity and as a result of that it is possible to end up with a bunch of direct connections between a myriad of different components or modules.

![Typical architecture diagram](/files/v3hclHtH7m04yWLuCeXF)

By using streaming patterns, it is possible to get a much cleaner architecture

![EDA architecture diagram](/files/uy7gy5HlLSOZNmZrKO8z)

It is important to take into account that EDAs are not a silver bullet, and there are situations in which this kind of architectures might not fit very well.

One example is systems that heavily rely on transactional operations... of course it might be possible to use EDA but most probably the complexity of the resulting architecture would be too high.

Also, it is important to note that it is possible to mix request-driven and event-driven protocols in the same system. For example,

* Online services that interact directly with a user fits better into the synchronous communication but they also can generate events.
* On the other hand, offline services (billing, fulfillment, etc) are typically built purely with events.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://adidas.gitbook.io/api-guidelines/asynchronous-api-guidelines/core-asynchronous-principles/b_basic_concepts_edas.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.