When would you keep a working stitched GraphQL gateway instead of moving to composition?

## Decide on the queue, not on the diagram Both models present clients with one endpoint and one schema. Nothing a client does distinguishes them. So the entire decision lives on the inside, and one question captures it: **when a client needs a field that crosses a service boundary, whose queue does that work enter?** Stitched: the gateway team's, always, no matter which team owns the data. Composed: the owning team's, and only theirs. That is the trade being purchased, and it is worth buying exactly when the queue is long enough to hurt. ## What composition actually costs Candidates who have only read about federation describe the benefits and skip the invoice. Say the invoice out loud: - **A composition step in the build**, which can fail — and when it fails, it fails closed. Two teams' declarations that cannot be merged mean no new graph is published, so an unrelated team's release is blocked by a schema conflict it did not cause. - **Schema publishing and versioning** — somewhere services register what they contribute, with history, checks and a promotion path per environment. - **A router to operate**: capacity, latency budget, deploys, and a pager. It is now the single component every client request passes through. - **Real changes in every backing service**: identifying fields declared, resolution by those values implemented, ownership of every shared field decided explicitly rather than left to a gateway rule. - **Ownership arguments made explicit.** Stitching lets a gateway rule quietly decide that the fares service supplies `Seat.price`. Composition makes some team declare it, and that conversation is sometimes months long. With nine contributing teams that invoice is obviously worth paying. With three teams in one department who ship together anyway, it usually is not, and saying so is a stronger answer than reciting the migration plan. ## The two blockers that are not about size First, **you cannot compose a schema you do not control.** Composition merges what each service declares, so a third-party schema, a vendor endpoint, or a frozen legacy service that nobody may redeploy cannot join a composed graph on its own. You can front it with a thin service you own that declares participation on its behalf — but notice you have just written the delegation rule again, in code, and you now operate the wrapper too. Second, **gateway-side transforms have no specified equivalent.** If your merged schema exists partly because the gateway renames types, hides fields and synthesises wrapper shapes over an old backend, composition offers no central place to do that. Every transform must become someone's real schema or someone's real service. That is often the true cost of the migration, and it is invisible on an architecture diagram. ## The signals that it is time Measure rather than assert. The useful indicators are all about the configuration behaving like a shared resource: - **Lead time for a cross-service field**, and how many people can approve it. If the median is measured in weeks and the approver set is one team, the gateway is the bottleneck. - **Rules nobody can explain.** In one seat-map graph, a third of the 41 delegation rules predated everyone on the platform team; that is drift with no owner. - **Staleness incidents.** A stitched gateway that snapshots remote schemas at start-up carries an ageing copy of every service's type system. When the seat-inventory team added a crew-hold value to a seat-status enum, the gateway kept serving its stale copy for eleven days, and the new value surfaced as an unattributable field error — the gateway's view of that enum did not contain it. Nobody owned the refresh because the refresh belonged to a configuration, not to a team. - **Growth rate of the configuration versus growth of the graph.** If rules grow faster than types, the central file has become the design. None of those is fixed by choosing a newer technique — they are fixed by moving the declarations to the people who own the data, which is what composition is for. ## What a strong answer sounds like Name the axis (who edits the join), price both sides honestly, name the two blockers that override team count, and then commit to a measurable trigger rather than a preference. Something like: "Below roughly a handful of contributing teams with no autonomy pain, I keep the stitched gateway and spend the effort on schema checks and a refresh policy instead. I move when cross-service lead time is dominated by waiting on one team, or when the configuration has rules nobody owns. And I would not attempt it at all until I know what the transforms in that configuration are going to cost, because that is the part that never appears on the plan." The weakest answer, and it is common, is that composition is the modern approach and stitching is legacy. That skips the invoice, ignores the schemas you do not control, and mistakes a technology preference for an organisational decision.