Federation and query complexity

Production GraphQL needs guardrails: **query cost**, **depth limits**, **timeouts**, and clear **service ownership** in federated graphs.

**Federation** (Apollo, GraphQL Mesh) composes subgraphs into one supergraph. Each team owns types; the gateway plans fetches across services.

					# users subgraph
type User @key(fields: "id") {
  id: ID!
  email: String!
}

# orders subgraph
extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}
				

Complexity controls:

• **Max depth** — limit nested selections.
• **Cost analysis** — assign weights to fields; reject expensive queries.
• **Persisted queries** — allowlist known operation hashes in production.
• **Rate limits** per API key / user / IP.

Entity resolution crosses service boundaries — monitor gateway latency and partial failures (nullable fields vs errors).

On interviews: when federation helps org scale, debugging cross-subgraph N+1, and why public GraphQL without limits is dangerous.

Common pitfalls: god subgraph, cyclic dependencies, exposing admin fields on the same graph as mobile, and no persisted operations in prod.

The trade-off is federated autonomy versus operational complexity — invest in schema registry, composition checks, and gateway observability.

Checklist:

• Depth and complexity limits in production.
• Persisted or approved operations for public clients.
• @key ownership documented per team.
• Gateway metrics: plan time, subgraph errors, p99 latency.