What is a federated gateway?

In centralized systems, a single gateway (itself connected to, and responsible for managing, multiple APIs) handles all client queries. Gateway federation, meanwhile, enables an organization to use a distributed network of API gateways, each responsible for its own distinct set of services.

In a federated gateway system, teams can add services as needed without impacting the entire system, enabling efficient resource usage and traffic management. Separate departments can also use different protocols to manage their respective gateways. The framework gives teams the latitude to manage their own APIs, improving flexibility, operational resilience and more.

This approach also helps avoid traffic bottlenecks and other issues associated with centralized API gateways and can deliver performance benefits by deploying gateway functions closer to end users. Gateway federation strategies can be applied to various API architectural styles and protocols, including REST, gRPC and SOAP, each offering benefits and drawbacks.

From an IT perspective, a federated gateway is beneficial because it enables DevOps teams to develop and deploy their own APIs while maintaining adherence to enterprise-wide API platform management, governance and security policies. Teams can move quickly and independently to complete projects in their domain (facilitating innovation and accelerating speed to market) while preserving organization-wide standards, striking a balance between team autonomy and centralized oversight.

GraphQL federation is an alternative concept and architectural approach that is used to create a unified GraphQL API. It is based on GraphQL, a query language that can accurately target resources from multiple services with a single API query.

GraphQL federation connects different services (known as subgraphs)—each with its own schema that defines the data it manages—to a unified schema known as a supergraph. A single gateway exposes this supergraph schema to client applications, unites multiple underlying services and fields and routes all API queries. In contrast, gateway federation connects multiple API gateways through a central control plane, with each gateway fielding its own queries.

Federation is a general approach to system management that connects autonomous components through a common control plane.

In a centralized gateway system, all client requests flow through a single gateway, which manages functions such as routing, authentication, authorization and monitoring. Unlike federated architectures, these responsibilities are not distributed across multiple instances.

This approach can streamline logging, traffic management, security enforcement and other tasks because each of these processes flow through the gateway. Organizations can also initiate rollouts from a single point, eliminating the need to version updates across multiple gateways and services.

However, companies with centralized frameworks might be more likely to encounter bottlenecks, especially as they scale up their operations. As the system’s single pass-through point, the gateway can easily become congested. In addition, it presents a single point of failure; if an error occurs, it affects the entire system.

Unlike centralized systems, federated gateway architectures are made up of multiple gateways, each responsible for a distinct set of services and associated APIs. The gateways function independently, although they are each managed by a central control plane.

Compared to centralized frameworks, federated systems promote flexibility and autonomy by giving development teams a greater level of control over their respective domains. This decentralized layout also makes federated systems more resilient against outages and system failures.

However, federated systems are more operationally complex, potentially introducing governance disparities and miscommunications between teams. Rollouts can take longer, and maintenance can be costlier, because each gateway must be managed and updated separately.

There are several reasons why an enterprise might opt for a federated gateway system.

For one, gateway federation is commonly used in cases of mergers and acquisitions, in which a company inherits different tech stacks and API management systems from the companies they acquire. Instead of individually managing multiple separate architectures—each with distinct security protocols, technical standards and governance structures—or trying to retrofit acquired systems with existing enterprise systems, enterprises turn to gateway federation. This approach enables organizations to fold existing API gateways, and their underlying systems, into the overlying structure provided by the central control plane.

Similarly, multiple gateways are often used in environments with many microservices built by different teams and spread out across different settings. An enterprise might also choose a federated system for performance benefits.

For example, consider a logistics company with several offices around the world, each serving a particular region. By placing gateways, servers, services and other resources nearer to the clients accessing them, the company can optimize for latency and related performance factors.

In gateway federation, the central control plane handles management, monitoring and governance but is generally inaccessible to clients. API consumers interact directly with the gateways that make up the federated system (querying the endpoint responsible for the relevant services) but do not query the control plane itself. The plane receives metadata and logs only after an API call has already occurred.

While this approach can introduce some operational complexity, it also promotes independence. For example, it helps enable platform teams to configure their own gateways and services to meet their specific needs, choose their own protocols and deploy rollouts on their own. Federated architectures are also more resilient to misconfigurations and security breaches because errors are isolated to the gateway that they originated from and are not likely to spread to other gateways in the network.

In GraphQL federation, meanwhile, the schemas from multiple independent services (subgraphs) are combined into one unified supergraph schema. A single gateway, or router, presents a single entry point for client queries, providing a unified API experience.  

The router intelligently splits queries into smaller sub-requests, retrieving relevant information from multiple subgraphs and compiling it into a cohesive response for clients.

Imagine a healthcare platform with separate services for:

• Patients: Managing patient details, contact information and medical histories
  
  
• Appointments: Scheduling and tracking upcoming visits
  
  
• Billing: Handling invoices and billing notifications

Instead of querying each of these endpoints with a separate API call, GraphQL federation presents a unified interface that enables clients—in this case, an app or dashboard that serves doctors or patients—to access a patient’s medical history, identify her next appointment and determine her outstanding balance with a single API call, rather than through three separate requests.

GraphQL federation provides a way to build a scalable GraphQL API in a distributed environment. The framework enables the independent development and deployment of services while providing a unified frontend for client queries. However, GraphQL federation can be prone to cost and complexity challenges, security vulnerabilities, congestion and redundancies.

Introduced in 2019, Apollo federation is a one implementation of GraphQL federation that uses special directives (such as @key or @extends) within the GraphQL schema definition language to define relationships between different types across subgraphs.

Although Apollo is a common solution, it isn’t the only GraphQL federation option available. Common alternatives include Hive, Mesh, Indigo and WunderGraph Cosmo, which each offer varying levels of customization. 

While fewer than 5% of companies had federated GraphQL systems in 2024, that figure is expected to reach 30% by 2027, according to research firm Gartner. Major cloud providers like Amazon Web Services (AWS) and Microsoft Azure, as well as code repositories like GitHub, also support GraphQL APIs with built-in observability and validation tools.

GraphQL federation has several distinct advantages, especially in its ability to streamline API access for clients. Teams can maintain a degree of independence by deploying, managing and scaling their own subgraphs.

But as a centralized framework, GraphQL federation is more vulnerable to security lapses, congestion issues and performance inefficiencies. It is also beholden to GraphQL schemas, whereas API gateway federation is compatible with multiple protocols.

In developing an API strategy, organizations decide whether to adopt a GraphQL API framework or use another architectural style, such as REST, for their APIs.

Ultimately, organizations might choose to incorporate both GraphQL federation and other architectural styles into their systems, with each responsible for handling different functions. In one common configuration, an enterprise uses GraphQL internally (with strict guardrails to mitigate security, cost or complexity concerns) and uses a different architectural style such as REST (which can provide a deeper level of control and easier adoption) for external APIs. In this scenario, a federated API gateway might also be used to unify these disparate architectural styles through the central control plane.

In standard API gateway configurations, a single gateway handles all user traffic, routing and analytics. While this approach helps streamline simpler setups, it can quickly lead to bottlenecks in more complex environments.

Federated gateways rely on not just a single API gateway but an array of them. Each gateway is used to manage API calls to a specific set of services, and the gateways are connected to the control plane, which handles management and governance.

Service meshes, meanwhile, are considered east-west configurations because they manage connections between microservices but do not interface with users themselves. Service meshes primarily facilitate communication and observability within a single environment or cluster. However, variants known as hybrid cloud meshes are optimized to perform functions like encryption, load balancing and authentication across multiple clusters and environments (including multicloud, hybrid cloud and on-premises environments). 

Organizations can use various strategies to take advantage of a federated gateway’s distributed architecture while reducing some of the operational complexities and maintenance costs associated with federated systems. These practices help preserve team autonomy while maintaining open lines of communication and unified oversight between teams.

Enterprises should draw clear distinctions between teams, eliminating ambiguities around which services each is charged with building and maintaining. This practice promotes accountability and protects teams from inadvertently duplicating or misconfiguring colleagues’ work. By extension, this approach can boost productivity because teams have a firm understanding of their goals and responsibilities (and the freedom to act on them).

The inconsistent implementation of security and compliance protocols and standards across gateways and APIs can present security, legal and reputational risks. Maintaining standards for logging, encryption, authentication and other security implementations across gateways must be a priority in a distributed system. Doing so helps ensure that the central management plane can be used to efficiently respond to incident reports, make comprehensive audits and prevent future attacks, no matter which domain a threat originated from.

Observability gaps in a distributed system can lead to security risks and performance issues. It is crucial that the central management plane provides the comprehensive visibility needed for teams to view system health and performance. This capability helps enable swift remediation when issues arise, as well as the ability to make proactive improvements based on security and performance metrics.

Unified developer portals act as centralized hubs where developers can access and learn about any API in the system, regardless of where they are hosted or how they are structured. They are especially important in federated systems because they provide guidelines, documentation and coding samples to give DevOps teams a clear framework for how their APIs should be built, deployed and maintained.

These universal standards, together with API keys and other access controls, help ensure that developers can seamlessly add APIs to the system and manage their own gateways while maintaining security and consistency.

Because each team acts with some degree of autonomy, open lines of communication are vital for sharing best practices and maintaining a sustainable network. Dashboards and other collaboration tools can help teams synchronize around shared goals and procedures, especially when a change in one domain might affect related services.

Comprehensive reporting mechanisms enable DevOps teams to quickly detect and address latency, service disruptions and other anomalies, contributing to a more seamless user experience. Performance metrics can also improve scale efficiency by identifying which parts of the system are reaching capacity and which are underperforming.

Modern DevOps approaches, such as infrastructure as code (using code to automate IT processes that would otherwise require manual oversight and provisioning) and AIOps (using AI to streamline IT operations) can help federated gateways operate more efficiently. Automation techniques also contribute to a more resilient network because they reduce the likelihood of human errors and give IT teams bandwidth to focus on more complex issues.

Gateway federation combines the flexibility and customization of decentralized architectures with a centralized governance structure and can offer several advantages over traditional architectures.

Federation gives teams control over their own gateways, enabling them to adjust runtime configurations, manage updates and customize coding environments to best match the needs of their clients and services. For example, to adjust the rate limit of an API in a centralized system, a team would need to submit a request through the organization’s single gateway. Federated systems enable teams to make the adjustment independently and in real-time, without impacting other gateways in the network.

The central plane helps ensure that multiple gateways, despite having their own configurations, abide by shared compatibility and safety standards. Teams have the flexibility to adjust parameters autonomously while benefiting from the external oversight provided by the control plane.

Federated approaches recognize that development teams often have the best idea of how to improve and maintain their own domains. Teams are given autonomy to adjust their APIs or services as soon as they see a problem emerging, improving adaptability and agility. 

Teams can even work across different coding languages while maintaining their service’s relationship with the central control plane. Finally, departments can roll out updates as needed instead of relying on a central authority to approve changes, improving time to market for new features and streamlining workflows.

Federated systems can offer more efficient resource provisioning by enabling teams to monitor their own performance and adjust rate limits and traffic distributions accordingly. Organizations can scale up only the services and functions that require extra capacity, funneling resources from less-used services or regions to those experiencing higher demand.

In addition, because API gateways are independent, it’s harder for vulnerabilities to jump from one gateway to another. As a result, federated systems are generally more resilient against attacks and outages because failures are likely to affect only a single gateway, rather than the entire system.

In federated systems, individual DevOps teams take on the operation and maintenance of their own gateways. With fewer responsibilities, the central team can focus on higher-level issues, such as enforcing compliance regulations, facilitating cross-communication between teams and refining system architectures.

Data silos are far less likely because a federated gateway can analyze performance and enforce guardrails across domains. Cross-gateway metrics can provide a more holistic view of how a particular service is impacting related products and services.

Decentralized ownership and flexibility can introduce several challenges, especially when there are breakdowns in governance or observability. Challenges introduced by federated gateways include:

While team autonomy can help drive innovation, it also adds architectural complexity to the system, driving up infrastructure and compute costs. Federated systems also tend to require more maintenance and security resources due to their decentralized structure.

Because metrics and logs are distributed across multiple API gateways, it can be more difficult for organizations to build a cohesive picture of overall system performance. Data sources can become fragmented and disconnected from the broader network, making it more challenging to identify and troubleshoot potential misconfigurations. Organizations can address this challenge with strong standardization protocols and principles, and with observability tools.

While individual teams can make updates at their own discretion, enterprise-wide rollouts might take longer than in centralized environments. Instead of updating a single central codebase, federated gateways must distribute updates across multiple domains, with each team responsible for approving and integrating those changes independently.

Maintaining consistent configurations and policies across distributed gateways can present a challenge. If teams adopt protocols, rollout schedules and data formats that deviate from enterprise governance standards, incompatibilities and security vulnerabilities can emerge. Contrarily, if standards and governance policies become too stringent, enterprises risk stifling experimentation and slowing the pace of innovation. In a federated system, balance is crucial.

As enterprises grow and evolve under a federated system, they risk introducing new inefficiencies, such as API sprawl, when multiple teams unintentionally develop redundant APIs. If this problem escalates, gateways can become unmanageable, with the central plane unable to track changes. This issue can be mitigated through efficient governance.