Throughout the last years, we really see a rise of API platforms!  The business cases behind these platforms vary from B2B/B2C marketplaces, over data-sharing initiatives towards exploration of new, innovative business models. Regardless of the scenario, there’s one fundamental question that always pops-up:  will the data be stored centralized or decentralized?  Let’s investigate the options!

Decentralized approach

In a decentralized setup, the API gateway is redirecting the requests to other API endpoints, which could be the ones of your backend application or a public API of your trading partner.  The API gateway is responsible to handle the required protocol, security and data transformations at runtime.

When using Azure PaaS components, Azure API Management has typically a big responsibility to execute all required transformations towards the backend services.  In case the logic becomes too complex, it can be offloaded to an Azure Function or API App, which serves then as a facade.

Centralized approach

In a centralized setup, the data is gathered in a central data store, which is part of the API platform.  This central data store has a near realtime bi-directional synchronization with the connected backend applications and business partners, established through asynchronous integrations.  In this scenario, the API requests are fired directly against the central data store.

When designing such a setup within Azure, a lot of the security, routing and data transformations are moved to asynchronous integration platform, which consists of Logic Apps that are connected in a loosely coupled way through Azure Service Bus.

Comparison

Below, you can find a comparison between the different approaches.

Conclusion

In case the business case allows it, I prefer the centralized approach.  This setup is more scalable, as it can guarantee the performance and uptime of the API platform.  A common pitfall of the centralized approach is the trust that is required between the different business partners, in order to agree on central data storage.  Another issue is that it’s not always possible from a business perspective to work against a copy of business data, as it should be sometimes a 100% realtime.

Taking into account the above, we often end up with a platform that handles most of the API requests in a centralized fashion, while some API operations are processed in a decentralized way because the business case demands it.

Hope you enjoyed this more architectural blog post!

Cheers
Toon