# Review GraphQL Federation Boundaries Before Implementing a Subgraph > Review GraphQL federation boundaries by checking entity ownership, fan-out, authorization, nullability, deployability, and failure isolation before adding a subgraph. Canonical URL: https://www.devobs.io/articles/graphql-federation-boundary-review/ By: Lucas Vale Published: 2024-11-09T17:23:24.645Z Updated: 2026-09-06T08:31:04.426Z Section: Architecture Federate GraphQL around domain and operational ownership, then test the composed query paths before implementing a subgraph. A clean schema can still conceal synchronous cross-service joins, broad failure propagation, and releases that require several teams. The boundary is sound when one team owns an entity's authoritative fields and common queries have bounded fan-out. ## Name the authoritative entity owner For each entity, identify the service that creates its stable key and owns its lifecycle. Other services may extend the entity with fields they own, but they should not compete to define the same fact. If billing and accounts both resolve `Customer.email`, a client cannot know which source wins and incident response becomes political. Apollo's [federation introduction](https://www.apollographql.com/docs/graphos/schema-design/federated-schemas/federation) describes declaratively combining multiple APIs into a single federated GraphQL API and routing client requests through a router that orchestrates requests across the graph's underlying APIs and data sources. Use that mechanism after domain ownership is clear. Directives and references can express a boundary; they do not create a healthy one by themselves. Review keys for stability and access control. As an engineering rule, avoid global entity keys that expose sensitive identifiers, and avoid boundaries that require an extra cross-service lookup just to make a basic authorization decision. Do not assume federation routing gives you authorization boundaries. Decide explicitly whether each subgraph enforces resource access itself or whether a separate centralized authorization layer does. ## Calculate fan-out from real operations Take the ten highest-volume persisted queries and draw their execution plans. A list of 100 orders that resolves customer, payment, and shipment per row can become hundreds of downstream calls unless resolvers batch by service and key. Batching removes repeated round trips but does not eliminate large downstream sets or expensive joins. As an engineering recommendation, consider limits for list size, depth, field cost, and downstream concurrency before allowing arbitrary operations from untrusted clients. The [September 2025 GraphQL specification](https://spec.graphql.org/September2025/) defines GraphQL as a hierarchical query language with client-specified field selection and a strong type system for executing operations against application services. Use those semantics to review failure domains. Review non-null fields carefully because GraphQL error handling can null parent selections when non-null guarantees are violated. Mark fields non-null only when the owning service can uphold that guarantee through realistic dependency failures. Avoid fields that require a subgraph to call back through the router, creating cycles. Prefer a query plan that moves from entity owner to bounded extensions. If two domains always need each other's data synchronously to answer basic queries, the service boundary may be wrong or a local projection may be needed. ## Make schema evolution independently deployable Add fields before clients use them, deploy supporting subgraphs, then release operations. Deprecate with usage evidence before removal. Treat changes to keys, nullability, enum values, or ownership as potentially breaking for composition or clients, and test composition plus representative operations in CI for every subgraph change. Keep rollback-compatible schemas across the deployment window. A useful review checklist is to track per-subgraph latency, errors, resolver count, batch size, query-plan signature, and visible null propagation. An incident in recommendations should not remove order IDs if recommendations are nullable and isolated. Define timeouts and partial-response policy at field boundaries, while ensuring mutations preserve business atomicity rather than returning partial success accidentally. ## Run an architecture review with evidence For each proposed entity, record owner, stable key, extended fields, authorization point, common query fan-out, nullability rationale, dependency timeout, and team on call. Execute representative queries against delayed and failed subgraphs. Verify your query-cost controls before allowing arbitrary operations from untrusted clients. Ownership also applies to mutations. A composed mutation should have one service responsible for the business transaction; resolver chains that write several subgraphs need an explicit [saga](https://www.devobs.io/articles/saga-compensation-design/) or compensation model. GraphQL mutations do not make distributed side effects atomic on their own. Reviewed: 2026-09-06. Revisit when the federation approach changes or a new GraphQL specification materially affects these recommendations. ## Source references - -