Distributed APIs
Architecture or organisational principle?
In the world of APIs, new terms regularly emerge that often cause more confusion than clarity. One of these is "distributed APIs". While some understand this to mean a technical architecture that promotes scalability and modularity, others equate the term with GraphQL Federation. In many cases, however, it remains unclear what exactly is meant by this – and, above all, what organisational challenges it entails.
Companies that introduce distributed APIs often expect greater agility, shorter development cycles and better interface reusability. But without clear structures and ownership, this approach quickly leads to inconsistent APIs, uncontrolled proliferation and increased maintenance costs. Instead of relying solely on technical solutions, organisations need to develop an overarching API strategy that takes both governance and team structures into account.
This post sheds light on what lies behind the concept of distributed APIs, the technological and organisational challenges that arise, and why success depends not only on architecture, but above all on organisational structure.
Distributed APIs and organisational structures: Conway's Law in action
APIs reflect the structure of the organisation that develops them – often without this being consciously planned. This phenomenon is known as Conway's Law and is particularly evident in the design of distributed APIs.
For a long time, centralised API teams dominated, managing interfaces and providing them uniformly via gateways. This approach ensured consistency but often made it difficult to make changes. With the introduction of microservices, the picture changed: APIs were developed in a decentralised manner to promote flexibility and autonomy among teams. However, this also increased the challenge of maintaining consistent standards.
Today, companies are faced with the question of how to embed APIs into a scalable architecture without losing control. Completely centralised control can slow down innovation, while a purely decentralised structure can quickly lead to inconsistent interfaces. An approach that is becoming increasingly important is ownership of APIs [see IT Spektrum 2/2025, https://www.sigs.de/artikel/api-ownership-warum-verantwortlichkeit-der-schluessel-zu-erfolgreichen-apis-ist/]. APIs are viewed as products for which dedicated teams are responsible – not only for development, but also for the entire lifecycle, including documentation and support.
Whether this approach works depends largely on the internal organisation. If teams are structured along business domains, APIs are created that reflect these domains. If, on the other hand, teams are organised according to technical layers, APIs that are oriented towards internal implementation details dominate. Companies must therefore be aware that their API architecture cannot be viewed in isolation, but always in the context of their organisational structure.
Distributed APIs as the basis for scalable IT ecosystems
Many companies rely on distributed APIs to make their IT architecture more flexible and scalable. However, the term is often misunderstood. An API is not automatically "distributed" just because it exists in multiple domains or is maintained by different teams. The decisive factor is how APIs are integrated into a company's overall strategy.
One of the main reasons for introducing distributed APIs is the challenge of providing data and business logic consistently across multiple systems. Especially in mature IT landscapes where monolithic applications coexist with microservices, a central API layer often makes things bottleneck. A distributed API architecture can help here by shifting responsibility to where the technical expertise lies – directly to the teams that know the respective business processes best.
However, this approach also brings challenges. Without clear governance, a variety of uncoordinated APIs can emerge that are difficult to manage. Companies must therefore find a middle ground between centralisation and decentralisation. While central API gateways can ensure security and consistency, self-service models enable flexible and efficient API usage. It is crucial that each API serves a clear purpose and is actively maintained by the teams responsible.
GraphQL Federation: a solution with limitations
GraphQL Federation (https://graphql.org/learn/federation/) is often seen as the answer to the challenges of distributed APIs. Instead of operating a central API layer, different teams can provide their own subgraphs, which are combined into a unified API schema. This architecture promises greater flexibility, as teams can work independently and make changes without having to adapt the entire API infrastructure.
In practice, however, federation is not always the best choice. One of the biggest challenges is the added complexity: managing a federated GraphQL schema requires well-thought-out governance to avoid conflicts between subgraphs. Without clear ownership, flexibility can quickly turn into a liability when changes to one part of the graph have unintended effects on other parts.
Performance can also become an issue. While traditional GraphQL gateways efficiently forward queries to the underlying data sources, federation can make s dependent on each other, increasing response times. This can lead to unexpected bottlenecks, especially in high-traffic systems.
Finally, security is a major challenge. In a federated architecture, access controls must be managed consistently across multiple subgraphs. Without a robust strategy, this can lead to fragmented permission structures that are difficult to maintain and secure.
GraphQL Federation can therefore be a useful solution for certain use cases, but it does not replace the need for a comprehensive API strategy. Companies should consider whether federation really suits their requirements or whether other architectural approaches – such as a combination of REST, GraphQL and event-driven APIs – make more sense.
The API strategy determines success
The success of distributed APIs does not depend solely on the technology, but on the strategy behind it. Companies that want to design their API landscape sensibly must first ask themselves what role APIs should play in their overall architecture.
Should APIs be managed centrally or decentralised? Which teams are responsible for what? How can you ensure that APIs remain consistent and reusable? These questions are essential before deciding on specific technologies.
A common mistake is to introduce a new architecture or framework as a panacea for existing challenges. GraphQL Federation, for example, does not solve governance problems – on the contrary, it requires even stronger control to function effectively. A sustainable API strategy is therefore based not only on technical considerations, but on a well-thought-out interplay between organisation, governance and technology.
A balanced mix of different API approaches can make more sense than a one-sided decision in favour of a particular technology. While GraphQL Federation is useful for aggregated queries, REST APIs offer stability and standardisation. Event-driven architectures, in turn, enable APIs to be used efficiently for asynchronous processes. Companies that use APIs strategically should therefore remain flexible and continuously adapt their architecture.
Conclusion: Distributed APIs are more than a technology decision
Distributed APIs can help companies make their IT architecture more scalable and flexible. But without a clear strategy, this approach can quickly lead to complexity and inconsistency.
Technology alone is not enough to create a successful API architecture. The decisive factors are how companies design their API governance, which responsibilities they define and how they ensure that APIs are meaningfully integrated into their business strategy. Those who think of APIs as a product and give teams ownership of the " " lay the foundation for a sustainable and successful API landscape.