Almost every team that adopts GraphQL eventually faces the same conversation: the schema has grown large enough that no single team fully understands it, merges are slow because multiple teams are touching the same file, and the gateway deployment pipeline has become a serialisation point that blocks everyone. At that moment, someone proposes federation. The proposal is presented as a routing improvement — split the schema across teams, compose it at the edge, and let everyone move independently. It is not a routing improvement. It is a decision about who owns what, and it requires answers that only leadership can give.
What the decision actually is
There are three architectures in play when someone says “we need to sort out our GraphQL.” The first is a monolithic GraphQL schema — one repository, one deployment, one team (or one team that acts as a bottleneck) that owns the schema. The second is schema stitching — multiple GraphQL services stitched together by a gateway that combines their schemas at query time through manual merge configuration. The third is Apollo Federation — multiple subgraph schemas composed automatically by a Router using federation directives, with each subgraph owned independently by a domain team.
The monolith is not wrong for small organisations. When three teams each own a clear domain and the schema has fewer than 200 types, a monolith is simpler to operate and easier to reason about. The cost of the monolith appears as the organisation grows: teams start waiting on each other for schema changes, the gateway becomes a single point of deployment risk, and the concept of “who is responsible for this field” becomes ambiguous. Federation does not eliminate these problems — it restructures them. Instead of one schema that everyone touches, you have multiple schemas that each team owns, plus a new coordination layer (the schema registry, the breaking-change policy, the Router deployment) that the platform team owns.
The question is not whether federation is technically superior to a monolith. The question is whether your organisation has the discipline to run it. Federation raises the ceiling on team autonomy and simultaneously raises the floor on governance maturity required to achieve it.
REST is not going away because GraphQL federation exists. Payment initiation APIs operating under SAMA’s Open Banking Technical Standards are defined as REST endpoints with specific response schemas. ISO 20022 message orchestration does not become a GraphQL mutation. Federation is an internal API architecture for consumer-facing products and internal BFF layers — it does not replace the machine-to-machine integration layer that runs on REST, SOAP, and ISO messaging standards. Leadership needs to be explicit about where federation applies and where it does not, or the architecture becomes a confused hybrid where teams try to build ISO 20022 payment flows as GraphQL mutations.
What the regulator cares about
A federated GraphQL surface presents specific compliance challenges that a REST API does not. The first is field-level access control. In a REST API, access control is per-endpoint: the AIS GET /accounts/{id} endpoint is accessible to TPPs with an AIS scope. In a federated GraphQL API, a single operation can span multiple domains. A consumer can request account data and transaction data and notification preferences in one query — and each of those fields may have a different access control requirement. The Apollo Router supports schema-level authorisation directives (@requiresScopes, @authenticated), but these must be explicitly applied to every sensitive field across every subgraph. A field that someone forgot to annotate is a field that any authenticated consumer can query, regardless of whether their scope grants access to it.
The second challenge is introspection exposure. GraphQL introspection returns the complete schema — every type, every field, every argument, across all subgraphs — as a structured JSON response to any client that sends an introspection query. In a SAMA-regulated environment, this is a detailed map of your data architecture. SAMA examinations will test whether introspection is accessible without authentication; it must not be. More subtly, even authenticated introspection exposes the full schema to any consumer with a valid token, including fields they are not authorised to query. In environments with strict data classification requirements, consider disabling introspection entirely in production and providing schema documentation through an authenticated developer portal instead.
The third challenge is the audit trail per subgraph team. SAMA’s Technology Risk Management framework requires that access to customer data be attributable to a specific system, a specific operator, and a specific time. In a federated architecture, a single client query may result in data being fetched from three subgraphs operated by three different teams. The audit trail must trace the full query plan, not just the entry point. This requires distributed tracing that propagates context from the Router into every subgraph fetch — and it requires that each subgraph team logs the received context with sufficient detail to satisfy a SAMA data access audit. This is an operational commitment from three teams, not just the platform team.
The trade-off the business owns
Federation offers a genuine autonomy benefit: the payments team can evolve the payments schema without waiting for the accounts team or the notifications team. They can deploy their subgraph, register the new schema, and have it live in the supergraph within their own CI/CD window. This is the appeal. The cost that is consistently underestimated is the coordination cost of schema contracts.
A subgraph schema is not a private implementation detail — it is a public contract that other subgraphs depend on through @external and @requires references, and that consumers depend on through registered persisted queries. Removing a field from the payments subgraph breaks any consumer that queries that field. Renaming a field breaks cross-subgraph references that @require it. The schema registry can detect these breaking changes and block the push, but someone has to decide the policy: what is the deprecation window, who is responsible for migrating consumers, and who has the authority to declare a breaking change acceptable given a short consumer migration timeline?
These are not engineering decisions. They are business decisions about how much disruption to consumers is acceptable during a schema migration, and they require a named owner — a schema governance board, a VP with authority over all affected teams, or a formal API change process with an SLA on consumer notification. Without that named owner, breaking changes get merged because no single team has the mandate to block them, and the audit-free merge history becomes a compliance liability.
What the team needs from leadership
Federation adoption at an institutional bank fails in three predictable organisational patterns. The platform team deploys the Router and registers subgraphs, but there is no policy on who owns cross-subgraph types: two teams both define a Money type, composition fails, and the release is blocked while engineers argue about ownership. The schema registry is deployed, but breaking-change checks are set to “warn” rather than “block” because a team lead overrode the block to ship a deadline feature — and the precedent removes the registry’s authority permanently. Persisted queries are planned but never enforced, leaving production exposed to arbitrary query injection from any consumer with a valid JWT.
Leadership needs to make four commitments before federation goes into a production environment that carries regulated data.
First: a subgraph ownership map. Before a line of federation configuration is written, every entity type in the current or planned schema must have a named owning team. This is not a technical exercise — it is a domain modelling exercise that may expose organisational ambiguities that have never been resolved. The payments team and the accounts team both have an opinion on who owns Transaction. Resolving that ownership question at a leadership level, before implementation, prevents it from becoming an unresolvable conflict mid-project.
Second: a breaking-change policy with teeth. Define the deprecation window (minimum 90 days is reasonable for a banking API where consumers are regulated entities with their own change processes), the notification mechanism, and what happens when a team misses the deadline. The schema registry’s breaking-change check must be set to block, not warn, and overriding it must require VP-level sign-off. A policy that exists in a wiki but cannot be enforced at the tooling layer is not a policy — it is a statement of intent.
Third: a schema governance board. Not a committee that reviews every schema change (that defeats the purpose of federation), but a named group that meets monthly to resolve cross-subgraph ownership disputes, approve breaking changes that are necessary and time-bound, and maintain the entity ownership map as the organisation evolves. This board needs authority, not just advisory status.
Fourth: a persisted query enforcement date. Set a date — no more than 6 months after the first production subgraph goes live — by which all production consumers will have migrated to sending operation IDs rather than arbitrary query strings. After that date, the Router enforces the allow-list. This is the control that prevents arbitrary query injection; without a hard deadline, consumers will not migrate voluntarily, and the enforcement date slips indefinitely.
Federation done right — with subgraph ownership defined, schema contracts enforced, persisted queries in production, and distributed tracing spanning the Router and all subgraphs — is a genuine improvement in domain team autonomy and API governance. It is worth the operational investment. The leadership decision is to commit to the governance framework before the technical implementation starts, or to accept that federation will produce the complexity without the autonomy benefit.
For the engineering depth behind these decisions — Apollo Federation 2 architecture, subgraph SDL with @key and @external directives, Apollo Router configuration on OpenShift, GraphQL-aware rate limiting with Kong, persisted query enforcement, and the production checklist — see the companion Lab article: API Gateway: GraphQL Federation at Scale.