How do you decide whether a company runs one GraphQL graph or several?

## "One graph" is a slogan before it is a decision The pitch is genuinely attractive: every client, one endpoint, every relationship traversable. It is also the kind of goal that survives on aesthetics long after the evidence stops supporting it. A principal engineer's job here is to convert it into tests that can come back negative. ## Test one: traversal The only capability a combined graph adds over two separate ones is the ability to select **across** the boundary in a single operation. So ask for the evidence: are there real client operations that would traverse from the fleet telematics domain into, say, the billing domain? Not "could imagine", not "someday" — recorded operations, or a screen someone is actually building. If the answer is no, joining the two graphs adds a shared namespace, a shared composition failure mode and a shared release surface, in exchange for nothing a client can use. Two graphs, cleanly separated, are the cheaper and more honest answer. Domains that never traverse are the strongest signal for separate graphs there is, and it is the test teams most often skip because the answer is embarrassing. ## Test two: who owns it on a Tuesday afternoon A shared graph is a product with an operator. Concretely, someone must own the composition step, the place schemas are published and versioned, the router in the request path, the breaking-change checks that run against recorded operations, the naming and deprecation policy, and the arbitration when two teams want the same type name. Say the candidate arrangement is 13 contributing teams and a 4-person platform team. That is workable — but only if contribution is self-service: composition checks run inside each team's own CI, publishing is automated, and the platform team is consulted for conflicts rather than for changes. The moment the platform team becomes a review gate, the shared graph has reproduced the release train it was built to remove, with more moving parts. If you cannot staff that team at all, one graph is not a plan; it is a promise you will be unable to keep. ## Test three: blast radius One graph is one failure domain in more ways than teams expect. Composition fails closed, which is the correct behaviour and also means one team's bad publish blocks everyone else's until it is resolved. The router is a single component every client depends on; its capacity, its rollout and its incidents are shared. A shared graph makes every team's worst day slightly more likely and considerably more crowded. Separate graphs give you failure isolation for free, which for a domain with a different availability target — a partner-facing graph with contractual uptime, say — may matter more than any traversal you would gain. ## Test four: audience and trust Internal and external consumers are not the same consumer. A partner-facing graph is a curated subset with explicit deprecation guarantees, a slower evolution rate, tighter authorization and a much smaller surface. An internal graph changes weekly and expects callers to keep up. Fusing them into one type system means the partner promise governs the internal pace, and the internal surface has to be actively hidden rather than simply not existing. The same logic applies to trust boundaries generally: if two parts of the business cannot share a namespace without a security review of every field, they probably should not share a graph. ## Reversibility, and which mistake is cheaper Ask which error you would rather make. Merging two graphs later is mostly a naming exercise plus a composition run — unpleasant but bounded. Splitting one graph that clients have been traversing for two years means breaking their operations, because a document that crosses the boundary simply cannot be expressed any more. That asymmetry argues for starting with more graphs than the slogan wants and merging on evidence. ## What to measure once you have chosen Whoever owns the decision should hold numbers on it: schema lead time per contributing team, how often composition fails and how long it stays failed, the share of recorded client operations that actually traverse a domain boundary, and how much of the platform team's week goes to arbitration rather than to the platform. If the traversal share stays near zero after a year, the graph was merged for tidiness and can be split back before more clients depend on it. ## The usual landing place Organisations that think this through rarely end at one graph or at one-per-team. They end with a small number of graphs aligned to **audiences** — an internal graph, a partner graph, sometimes one for a distinct product line — each composed internally from the services that genuinely traverse each other. That shape gets most of the traversal benefit, keeps failure domains and evolution rates separable, and is small enough for a platform team that actually exists to operate.