In GraphQL schema stitching, what does the gateway hold that the services do not?

## The question behind the question Interviewers rarely care whether you can recite two definitions. They are checking whether you know **where the joining knowledge is written down**, because that single fact predicts everything else: who reviews a cross-service change, what breaks when a service renames a field, and what a migration costs. Hold one example in mind throughout: an airline seat-map graph. A seat-inventory service owns `SeatMap` and `Seat` for a flight. A separate fares service owns what each seat costs. A client wants `Seat.price`. ## What a stitched gateway actually contains In stitching, both services are already GraphQL servers. The gateway does three things. First it **acquires the remote schemas** — usually by introspecting each service at start-up, or by reading SDL files checked into the gateway's own repository. Note the consequence immediately: the gateway now holds a *copy* of each service's type system, and that copy has an age. Second it **merges the type systems**, resolving conflicts by configuration. The fares service also has a type called `Seat` — a fare row, not a physical seat — so the gateway renames one of them, or filters it out of the merged schema entirely. Third, and most importantly, it holds **delegation rules**. A rule says: the field `Seat.price` on the merged `Seat` type is not resolved by either service directly; to resolve it, take the already-resolved parent `Seat`, read its `flightNumber` and `seatNumber`, call the fares service's `seatPrices` operation with those values, and graft the result into the response at that path. Every one of those three things is written in a file the gateway team owns. The inventory service does not mention fares. The fares service does not mention seat maps. That is genuinely the appeal — you can stitch two services you did not write and cannot change, including third-party ones. ## What a composed graph contains instead Composition moves the same knowledge into the services. The fares team writes, in its own schema, in its own repository: this graph's `Seat` is identified by flight number and seat number, and I contribute a `price` field to it. A composition step reads every service's published schema and merges the declarations into one graph, which a router then serves. No central mapping file exists. When the fares team wants to contribute another field, it edits its own schema and deploys on its own cadence. When a new service joins, it declares its own participation. ## The consequence, stated as a test you can apply Ask: *a client wants a new field that crosses a service boundary — whose pull request is it?* - Stitched: the gateway's. However well-intentioned the gateway team is, cross-team work now queues behind one team's review, and that queue is the thing that grows with the organisation. - Composed: the owning team's. The gateway team's job shrinks to running the router and keeping composition healthy. This is why the choice is usually described as an organisational one rather than a technical one. Both approaches produce one endpoint and one schema for the client; the client cannot tell them apart from the outside. ## Specified, or merely conventional? Be precise here, because it is a standard follow-up. **The GraphQL specification says nothing about combining schemas at all.** It defines one type system, one document language, and one execution algorithm over a single schema. Stitching is therefore a library technique — different implementations spell the configuration differently, and there is no standard for it. Composition is standardised, but not by GraphQL: the Apollo Federation specification defines the directives a service uses to declare its contribution and the rules by which those declarations merge. That is a separate document layered on top of GraphQL. One asymmetry follows directly and often trips candidates up. A stitched gateway can rename, hide, wrap or otherwise transform a remote schema before merging it, because it is just configuration in one process. The composition specification defines no gateway-side rename: two services declaring a type with the same name are declaring the *same type*, and a conflict is fixed in the owning service's schema or by the two teams agreeing on one definition. Any tool that offers a transform on the composed path is offering something the specification does not. ## Why the distinction outlives the technique Stitching is the older approach and much less common in new systems, so it is tempting to file it under history. Interviewers still ask because plenty of production graphs are stitched, and because the underlying axis — central configuration versus distributed declaration — recurs everywhere. If you can name where the join lives and who edits it, you can answer the migration and the ownership questions that follow without having memorised anything else.