When a GraphQL schema is assembled from several SDL documents, what actually depends on their order?

## The setup A single seat-map service outgrows one SDL file, so its schema is split across seven documents: seating, inventory, holds, boarding, loyalty, pricing and a small root document. Several of them carry `extend type SeatMapQuery { ... }`. The documents are read once, assembled into one type system, and validated — all before the service takes its first request, which is why a peak of 1,200 requests a minute pays nothing at all for the split. The question an interviewer is really asking is: what changes if the documents are read in a different order? ## Meaning does not depend on order Three properties combine to make this true, and being able to name them is the answer: 1. **Extensions are additive.** An extension can add a field, an interface, a directive, an enum value, a root operation type. It cannot remove or replace anything. 2. **Collisions are errors, not decisions.** A field name declared twice across a type's definition and its extensions fails type-system validation. There is no last-one-wins rule to be sensitive to order in the first place. 3. **Validation applies to the assembled type system**, not to each document as it arrives. “The type must already be defined” is a property of the finished set, so an extension may textually precede the definition it extends within the set. The consequence people should take away is stronger than “order does not matter”: **ordering can never be used as a mechanism.** You cannot arrange for a later document to relax a nullability, retype a field, or shadow a definition. That is precisely why several teams can safely write into one type — nobody can quietly change the meaning of somebody else's field, whatever the load order. The one honest caveat is on point 3. Tools differ in how strictly they validate incrementally rather than on the assembled whole, so an extension placed before its definition can build in one toolchain and fail in another. It is legal, and it is still not worth relying on. ## What genuinely varies **Field order in the printed or introspected schema.** When a tool prints the assembled type system back out as SDL, or an introspection result enumerates a type's fields, the sequence reflects how the type was built: original definition first, then each extension's contributions in assembly order. Rename a document, change a glob, add a file, and that sequence moves. This is where the real incident lives. A team checked the printed schema into the repository and had the build fail if it differed from the committed copy — a reasonable way to make schema changes visible in review. Then a document was renamed, the assembly order shifted, and the next build produced a diff of several hundred moved lines describing exactly zero semantic change. After the third such diff the update became a reflex: regenerate, commit, approve. The change that eventually slid through unnoticed was a genuine field removal, hidden in the churn of a reordering. The fix is two-part and both halves matter. **Make assembly deterministic** — an explicit ordered list of documents, or a sorted glob, so the same inputs always produce the same artefact. And **compare type systems, not text** — an order-insensitive comparison that reports added, removed and changed definitions, so a move is silent and a removal is loud. ## The other ordering assumption, and why it is simply false The same conversation often surfaces a belief that schema declaration order determines the order of keys in a response. It does not. A response object preserves the order of the **client's selection set** — the order the fields were requested in — so reordering the schema changes nothing a client sees, and reordering a document's selections changes it for that client only. Any downstream consumer reading a response by key position is broken already, and moving a field in the SDL is not what broke it. ## Provenance disappears One more thing assembly destroys: which document contributed what. Introspection shows a merged type. A client cannot tell that `upgradeEligible` came from the loyalty document and `number` from seating, and neither can a printed schema. If ownership matters — and with seven documents and several teams it does — it has to be recorded outside the type system: directory ownership rules, a review policy, or a build check asserting which document is allowed to declare which fields. The schema itself will not remember. ## What a strong answer sounds like Separate the two layers in the first sentence. The type system is order-independent, and say *why* — additive extensions plus collisions as errors, which is a safety property rather than an accident. The artefact is order-dependent, and that is an operational problem about diffs and review rather than about correctness. Then name the discipline: deterministic assembly, semantic diffing, and ownership tracked outside the schema.