Query, Mutation, Subscription — Core Operation Types

GraphQL's three operation types differ in execution semantics, not just intent — understanding the difference prevents subtle bugs and incorrect assumptions about ordering and consistency.

Queries — parallel, side-effect free:

• Query fields resolve in parallel because the engine guarantees they are side-effect-free; it may safely run user, orders, and recommendations concurrently
• Writing to a database inside a query resolver violates this contract and risks race conditions — the engine may call it from multiple threads simultaneously

Mutations — serial, with manual rollback:

• Mutation top-level fields execute serially in document order by design — if you batch createOrder and chargePayment in one mutation document, they run in written order
• Critically, there is no automatic rollback — if chargePayment fails, the order is already created; compensating logic is your responsibility
• For complex multi-step mutations with rollback requirements, consider saga patterns or service-level transactions behind the resolver

Subscriptions — persistent connection, different infrastructure:

• Subscriptions break the request-response model: the client subscribes once and the server pushes events over WebSocket; in Spring Boot, return a Flux from @SubscriptionMapping fed by a Reactor sink
• The practical consequence most people miss is the transport split: queries and mutations are plain HTTP POST, so existing security filters and load balancers work; subscriptions need WebSocket infrastructure with its own auth flow, reconnection logic, and backpressure handling

I recommend keeping subscriptions on a separate concern from queries and mutations in your architecture — different transport, different auth model, different infrastructure requirements.