Field Ownership Directives

## Ownership is the default, sharing is the exception Composition turns several subgraph schemas into one supergraph schema, and the router uses that supergraph to build a query plan. For every field the plan touches, the router must answer one question: which subgraph do I call for this? The default answer in Federation 2 is "the single subgraph that declares it". If two subgraphs declare `Locker.address` and neither says anything more, composition fails rather than picking a winner — because a graph where the answer depends on the plan is a graph where the value depends on the plan, and query plans change as the schema and the client's selection change. `@shareable` changes that answer. Applied to a field, it declares that this field may be resolved in more than one subgraph. Applied to an object type, it applies to every field of that type. ```graphql # Lockers subgraph type Locker @key(fields: "id") { id: ID! status: LockerStatus! @shareable } # Reservations subgraph type Locker @key(fields: "id") { id: ID! status: LockerStatus! @shareable activeHolds: Int! } ``` ## It is a claim, not a permission The rule candidates most often get wrong: `@shareable` is not something the owner grants to the others. It is a statement each subgraph makes about its own declaration, so **every** subgraph that resolves the field must carry it. Mark it in Lockers and forget Reservations, and composition still rejects the pair, because Reservations is still asserting sole ownership of `status`. Two categories need no marker at all. Entity key fields are implicitly resolvable everywhere: any subgraph that references `Locker` has to be able to return the fields inside its `@key` so the router can build a representation, so the duplicate-declaration rule does not apply to them. And a field marked `@external` is not a second implementation — it is a reference to a field owned elsewhere, declared so this subgraph can mention it in a key or in another ownership directive. ## Value types are where this shows up first The common encounter is not entities but *value types*: plain object types with no `@key` — `Address`, `Money`, `TimeWindow` — that several teams want in their own schemas. Federation 1 merged identical value-type definitions silently. Federation 2 reversed the default: each shared field must be marked, or the whole type marked. That is more typing, and it is deliberate. "Several teams own this shape" becomes a decision someone wrote down rather than a merge that happened quietly. ## The part nothing enforces `@shareable` is a promise about behaviour, and neither composition nor the router checks it. The router is free to satisfy the field from whichever subgraph its plan already needs to visit, and it will generally pick the one that saves a fetch. Take a parcel-locker graph where `Locker.status` is shareable. The Lockers subgraph derives it from the device's last heartbeat. The Reservations subgraph derives it from booking state, because it already has the booking row loaded. Now: - `query { locker(id: "L-4471") { status } }` starts in Lockers and returns the heartbeat view. - `query { reservation(id: "R-88213") { locker { status } } }` is already inside Reservations, which can answer without a second fetch — so it returns the booking-derived value, and Lockers is never called. Same field, same client, two answers, and no error anywhere. Worse, the behaviour moves under you: a change to an unrelated part of the query, or to the planner, can flip which implementation answers. This is why the complete interview answer is "it lets several subgraphs resolve the field **and obliges them to agree**", not just the first half. There is a latency face to the same trap. If Reservations computes `status` from a row it already loaded but Lockers calls a device registry, then a plan that routes through Lockers adds a hop the other path does not have. A field that is free on one route and 90 ms on another makes a 340 ms p99 budget a lottery decided by query shape, and the p99 regression will look like it came from nowhere because no subgraph got slower. ## When not to reach for it Prefer a single owner and let other subgraphs reference the entity by key. Reserve sharing for fields that are cheap, stable and genuinely denormalised in more than one store — a display name, a formatted amount, a status that is a true copy. Anything with business logic behind it should have one home. If two teams disagree about what a field *means*, `@shareable` will not settle the argument; it will hide it behind a query plan.