When would you take file bytes out of a GraphQL API and use signed upload URLs instead?

## What changes when bytes go through the graph With the multipart convention, every hop between the client and the resolver carries the file. In a single-service graph that is unremarkable. In an 11-service graph it is a design decision with consequences at each hop: a body that is no longer JSON, a request that occupies a connection and a request slot for the duration of the transfer, and a composition layer in front of the subgraphs — a federation router, say — that generally forwards JSON and has to be specially arranged to forward anything else. Uploads become the one request shape that is exceptional everywhere. ## When the multipart route is right Keep the bytes in the graph when the file is small and its meaning is inseparable from its metadata. A 240 KB condition photo attached to an accession record is the clean case: one round trip, one authorization decision made by the same field authorization as every other mutation, one transaction, and no state in which the photo exists but the condition report that explains it does not. No new lifecycle, no second service to reason about, no cleanup job. ## When to move them out Switch when any of these is true: - **Size.** A 380 MB master scan should not occupy a request slot on a service whose job is resolving fields, and should not be sized against request handling that exists for JSON. - **Reliability.** A transfer that takes tens of seconds over a bad link needs retry and resume. Storage services offer that natively; a mutation does not, and a retried mutation is a repeated upload. - **Path length.** The more services and intermediaries in front of the graph, the more places a non-JSON body has to be understood. Direct-to-storage collapses that to one hop. - **Locality.** Direct upload lands at an ingest endpoint or a CDN edge near the client rather than at wherever the graph happens to run. ## The shape of the flow Three steps. A `requestAssetUpload` mutation authorizes the intent, records a **pending** asset row, and returns a signed URL scoped to one storage key, one declared content type and a short expiry. The client sends the bytes directly to storage. An `attachAsset` mutation then binds the stored object to the domain record — and this is where verification happens: read the stored object's real size and type, do not trust what the client declared at step one, and make the attach idempotent so a retried call is harmless. ## The authorization point moves This is the part interviews probe. The signed URL is a **bearer credential**: whoever holds it can write those bytes. So the decision "may this caller upload here" is made by the minting mutation, not by storage, and the signature has to be narrow — one key, one method, a bounded content type, minutes not hours of validity. A URL scoped to a prefix rather than a key lets a caller write objects it was never authorized to write, and a long expiry turns a leaked log line into a standing write grant. ## The lifecycle you have just bought Two phases mean two failure states. An object uploaded whose attach mutation never arrives is an **orphan**: bytes with no record. A pending record whose upload never happens is the mirror image. Neither exists with a single mutation. Close them deliberately — pending rows expire, a sweep deletes stored objects with no attachment after a grace window, and the attach path tolerates being called twice. **An ordering assumption that broke.** In one museum digitisation pipeline the storage service's own object-created notification and the client's attach mutation raced. The notification handler, running in a different service from the one that minted the ticket, arrived first, found no pending row — the minting transaction had not yet committed and replicated — concluded the object was an orphan, and the nightly sweep deleted 63 master scans that had uploaded perfectly. The code was right about every individual step and wrong about the order they could occur in. The fix was not faster replication: it was to make the sweep act only on objects older than the grace window, and to make the notification path create-or-update rather than assume the record already existed. ## How to answer Do not present one route as modern and the other as legacy. Say what each buys: multipart buys atomicity and one authorization decision, signed URLs buy scale, resumability and a graph that never holds bytes. Then say where you draw the line — a size threshold, a rule that anything a user can retry belongs directly in storage — and what you built to close the orphan window. An interviewer wants the second half as much as the first, because the two-phase lifecycle is where teams actually get hurt.