Event Exchange Models in API-Led Connectivity

API-led connectivity forces the architectural restriction that Experience APIs must only invoke Process APIs, Process APIs must only invoke System APIs or other Process APIs, and System APIs must only interact with backend systems. This constraint affects the order and predictability of the interaction patterns in an application network.

When Event-Driven Architecture is applied in the context of API-led connectivity then the application components exchanging events are predominantly API implementations.

Event-Driven Architecture by itself is agnostic about the three tiers of API-led connectivity and hence does not restrict event exchanges between API implementations in different tiers. But breaking the communication patterns of API-led connectivity through arbitrary, unrestricted event exchanges risks destroying the order and structure created in an application network by the application of API-led connectivity.

In this way, destinations belong logically to the same API-led connectivity tier as the API implementation publishing events to them. 

• A System API publishes events to destinations that logically belong to the System API tier and can hence be described as "system events".
• A Process API publishes events to addresses that reasonably relate to the Process API tier and can hence be described as "process events".
• A Experience API publishes events to destinations that logically belong to the Experience API tier and can hence be described as "experience events".

Any API implementation that consumes events must not do so from a destination that belongs to a higher tier than the consuming API implementation itself. In other words, events must not flow downwards across the level of API-led connectivity:

• Events published by Experience APIs to their destinations ("experience events") must not be consumed from those destinations by Process APIs or System APIs.
• Events published by Process APIs to their purposes ("process events") must not be applied from those destinations by System APIs.
• Put differently: Events may only be consumed within the same tier or in higher levels relative to the API implementation that publishes the events.

The logic for this rule is the same as for the communication patterns underlying API-led connectivity: the rate of change of Experience APIs (which are relatively volatile) is higher than the rate of change of Process APIs which is higher than the rate of change of System APIs (which are comparatively stable). And a slow-changing component must never depend on a rapidly growing component.

Besides, in analogy with API-led connectivity, it should be prohibited that Experience APIs directly consume events published by System APIs, through ignoring Process APIs.