Challenges imposed by any digital business are generally focused on agility and scalability. Yet, nowadays, traditional software architectures don’t support the volume of data and integration patterns required to enable a competitive business. Implementing alternative solutions to make digital assets available in a secure and scalable way is key to the success of a company’s digital journey.

What Are APIs?

There are a variety of ways to define what an API is. In short, APIs are technical interfaces that enable the construction of integrated ecosystems. By developing digital products and leveraging their connectivity through APIs, it is possible to connect to a variety of partners, deliver services to app developers, and enable reusability of internal services, among other benefits.

REST is the most common style utilized by API exposers. However, new alternatives like GraphQL or gRPC have emerged. Depending on the use case (internal integration across microservices or flexibility for developers to choose what data they want in the response), these new styles can bring more benefits to an integration strategy.

What is an Event?

An event is any action that provokes a systemic change of state. In other words, an event is an update in an application that generates value to someone (through another app).

For context, consider events within a credit card payment system. Every time a user attempts a payment with their credit card, a notification is generated to inform or request confirmation. Note not every action or update executed in an application is considered an event. Instead, events should always be tied to meaningful business value.

Within an integration based on Events (also known as Event-Driven Architecture (EDA), consumers subscribe to events and receive notifications from them. This is opposed to the integration model defined by traditional APIs, where consumers make pool requests to obtain the information they need. Three main elements compose an EDA:

• Event Producer: responsible for the event generation.
• Mediator or Broker: Acts as the event distributor.
• Event Processors/Consumers: The components interested in an event.

There are two main topologies to implement an Event-Driven Architecture, using a Mediator or Broker:

Mediator

A Mediator is considered in scenarios where there are requirements for manipulating or orchestrating the event.

Mediator

Event Producers post events on a queue to be consumed by the Mediator. This can either be notified of the new event or proactively read the queue. Then, the Mediator will perform orchestration of the event by sending it in the right order to the different Processors, and even enriching the event with content coming from previous services if necessary. For example, in an order generation process, a service responsible for stock management is interested in getting notifications when products are added in a shopping cart, to inform their availability. And the invoicing service will need to know if there are products available in order to generate the order invoice.

Broker

In situations where there are no requirements for orchestration, the recommendation is to adopt a Broker.

Broker

Similar to Mediation, the event will be shared with the Broker (via poll or push, depending on the architecture decision made). The main difference is that the event will be sent to all Event Processors interested in this event. Following our previous example, the shopping cart, upon the generation of a new order, the order management service would send an event notification to the stock management service queue. If there are products available, this service could then send a new event notification to the invoicing service queue to generate an invoice.

Deciding between Mediator or Broker is an architectural decision that will depend on the requirements and business problems you are trying to solve.

How Do APIs and Events Coexist?

Although both models seem to oppose each other, they are, in fact, complementary to one another. In a hybrid scenario, APIs leverage online interactions where applications require instant feedback for the actions performed, while Events leverage asynchronous communications. Both technologies combined can be very powerful. This combination can enable companies to allow customers or partners to take the best of the synchronous word in two ways: first, when making API calls to creating orders or initiating payments and, second, when retrieving tracking updates after receiving an Event notification.

There are implementations of Event-Driven Architectures that deliver not only the notification itself but also the updated content. But even in this approach, an API could be triggered internally to retrieve the updates to be delivered to the subscribers of the Event.

A Real-World Scenario

It’s not hard to think of scenarios mixing APIs and Events. We can look to the world of Open Banking, a burgeoning field for APIs, for some excellent insights.

Banks play a crucial role in Open Banking, as they hold most of the customers’ details. Third-Party Providers (TPPs), on the other side, are interested in the customer data to power various use cases. These areas include the most affordable mortgage option, the best insurance provider, or even account aggregation, which puts all savings and current account details from different banks in a single view.

The way TPPs retrieve bank data is through API calls. But, should a solution initiate a new API call every time one opens an app to check the health of their accounts? The answer is no! Using Events, TPPs can be notified only when something changes. Triggering an API to update information only when needed avoids wasted calls. This is a simple example where APIs and Events can be combined to deliver real value to the entire ecosystem.

Conclusion

An integration strategy based on synchronous and asynchronous capabilities can be very beneficial to both API consumers and providers. Consumers don’t need to build their integration based on constant pooling requests sent to providers. These can offer an integration model that reduces the load on their servers and targets important business moments.

Before deciding the integration model, it is very important to identify your target customers and partners, as well as the best way to integrate with them to provide your services. Only after completing this analysis can the most suitable integration model be defined.