A GraphQL endpoint answers every read and write as a POST to one URL. How do you stop an automatic retry duplicating a write?

## Why the shape causes this Every request to a GraphQL endpoint looks the same from the outside. Same URL — one endpoint serves the whole schema. Same method — a POST, because the body is JSON. Same headers. The only thing that distinguishes `menuBoard` from `placeOrder` is a word inside a JSON string inside the body. HTTP's own machinery for deciding what may be repeated works entirely on the method. That machinery is everywhere: default retry policies in HTTP client libraries, connection-level retries in load balancers and sidecar proxies, user-driven refreshes. Point any of it at a GraphQL endpoint and it is working blind — it sees POST, applies whatever POST policy it was configured with, and cannot tell a repeat-safe read from a write. The failure has a specific shape. A client posts `placeOrder`. The server validates, charges, commits the row, and starts writing the response. The connection drops, or the client's deadline expires first. The client sees a timeout, which tells it exactly nothing about whether the server committed. If a retry policy sits underneath it, a second `placeOrder` executes and the customer has two orders. In an internal graph of eleven services, where the request crosses several hops each with its own defaults, the retry usually turns out to have come from a layer nobody remembered configuring. ## Ranking the fixes **Stop retrying from layers that cannot classify.** The most reliable change is also the least clever: turn off automatic retries for the graph endpoint everywhere below the code that composed the operation. That code knows the operation type, knows whether the mutation is repeat-safe, and can back off intelligently. A proxy layer cannot know any of it. This is a configuration and review problem more than an engineering one, and it is the change that actually prevents the incident. **Make writes repeat-safe in the schema.** Retries do not disappear; users press buttons twice and networks fail mid-flight. The durable answer is to let the mutation accept a client-generated key — a value the client creates once per user intent and reuses across every attempt — and have the server record the key with the outcome. A replay finds the recorded outcome and returns it instead of performing the work again. Two design points matter. The key belongs in the schema as an input field, not in a header: it is then typed, visible in the document, validated like any other input, and it survives being carried by any transport. And it must be generated at the point of *intent* — when the customer taps Place Order — not per HTTP attempt, or every retry invents a fresh key and nothing is deduplicated. **Let reads say they are reads.** Where a document is short enough to fit in a URL, sending query operations over GET restores the signal that the transport lost: the method itself now says this request is safe to repeat, and generic retry logic becomes correct rather than lucky. It does nothing for mutations, which is why it is the third fix rather than the first. ## Things that look like fixes and are not Appending the operation name to the URL as a parameter, or copying it into a header, makes traffic legible in logs and dashboards. That is worth doing for other reasons, but no generic retry policy is going to learn from it what is safe to repeat, and the body remains the authority on what actually executes. Giving mutations their own URL would restore the distinction, at the price of breaking the single-endpoint assumption every client and tool is built on. It is worth being able to discuss, and worth rejecting for a general graph. Relying on the server to notice "this looks like a duplicate" without a client-supplied key means guessing from field values and timing. Two genuinely separate identical orders exist — the same customer really can order the same coffee twice in a minute — so a heuristic either drops real writes or misses replays. ## What an interviewer is listening for First, that a timeout is not evidence of anything: the request may have fully succeeded and only the response was lost. Second, that the responsibility sits with whoever can read the operation, which means the client, not the transport. Third, that repeat-safety is a schema design decision — the key is part of the mutation's input contract, agreed with clients, not a piece of infrastructure bolted on afterwards.