How do you prevent over-fetching and optimize GraphQL resolvers?

Long Answer

GraphQL avoids rigid REST endpoints, but without discipline it can enable over-fetching (clients ask for too much) or under-fetching (schemas force multiple round trips). I use a mix of schema design, query governance, efficient data access, and caching to deliver predictable performance while preserving flexibility.

1) Schema design that matches real jobs

Start with consumer journeys and model task-oriented fields rather than dumping database tables into the graph. Expose connections with first/after (or limit/offset when safe), plus filters and sort arguments so the client can shape results without pulling entire lists. Prefer specific fields for common summaries (e.g., orderCount, totalAmount) instead of forcing clients to aggregate locally.

2) Guardrails against abuse and mistakes

Implement depth and complexity limits. Each field carries a cost; lists multiply cost by requested size. Cap query depth and total cost at the gateway; reject or require whitelisting for expensive shapes. Add persisted queries to remove ad-hoc explosions and enable caching keyed by a stable hash. Enforce max page sizes and sane defaults; forbid wildcard fragments that expand unbounded lists.

3) Kill N+1 with batching and selection

Most hot paths fail due to N+1: resolving a list and then loading children one by one. I adopt DataLoader-style batching per request: resolvers collect keys and issue a single bulk fetch, preserving order. For SQL, I prefer joins or IN queries with column projection driven by the GraphQL selection set. For NoSQL, I batch getMany and denormalize read models for top queries. I keep loaders scoped to the request to avoid stale data and to enable per-request memoization.

4) Push computations down

Move aggregations to the data tier when accurate and fast (SQL GROUP BY, materialized views, search backends). Avoid stitching results in userland when the database can compute them in one pass. Where cross-service composition is needed, use federation or a BFF that composes subgraphs with parallel I/O and timeouts per sub-request.

5) Caching at the right layers

Caching in GraphQL is layered:

• Per-resolver memo within a request avoids duplicate fetches.
  
• Loader cache for identical keys in scope.
  
• Entity cache (Redis) for stable records with short TTL and cache stampede protection (jitter, single-flight).
  
• Response cache for persisted queries with static variables; purge on writes or via tag-based invalidation.
  I make caches idempotent, include version tags, and invalidate by entity or list segment, not global nukes.
  

6) Pagination and under-fetching fixes

Always return pageInfo (hasNextPage, endCursor) and edges/nodes so clients can iterate without guessing. Offer field selection and targeted sub-resources to avoid follow-up queries. If a screen needs “list + summary + permissions,” expose a field that returns a composite view atomically, rather than three separate round trips.

7) Resolver ergonomics and safety

Resolvers must be pure and cheap: validate inputs early, short-circuit on errors, and avoid heavy transformations. Respect context for auth and tenant scoping; compute authorization once and share downstream. Add timeouts, circuit breakers, and bulkheads for downstream calls so a slow dependency does not freeze the graph. Keep the event loop clear; offload CPU-heavy work to workers.

8) Observability and governance

Enable tracing (Apollo/OTel) to capture per-field timing and N+1 hotspots. Track p95 latency per operation, cardinality of variables, error rates, and cache hit ratios. Add operation registry: only vetted queries run in production. CI enforces breaking-change checks and a complexity budget. Provide a “slow query report” to product teams and tune schema where clients struggle.

In essence, GraphQL performance is a contract: give clients just enough structure and controls to shape data, then make resolvers batch, cache, and compute efficiently with safety rails and visibility.

‍

Table

‍

Common Mistakes

• Designing schema as a mirror of tables, forcing clients to over-fetch and aggregate.
  
• No depth/complexity controls; one query can pull millions of rows.
  
• Ignoring N+1; resolvers loop child loads per parent.
  
• Using global, cross-request DataLoader caches that serve stale data.
  
• Unbounded page sizes or offset pagination on huge collections.
  
• Caching whole responses for highly dynamic queries (low reuse), skipping entity cache.
  
• Doing heavy joins in userland when the database can compute in one pass.
  
• Missing per-field tracing; teams optimize blindly.
  
• Authorization computed in each resolver repeatedly, wasting CPU.
  
• No persisted queries; caches miss and WAF rules cannot reason about operations.
  
  

Sample Answers

Junior:
“I expose connections with filters and limit page sizes. I use DataLoader to batch child fetches and avoid N+1. I also add basic depth limits and per-request memoization so repeated field reads are cheap.”

Mid:
“I design task-oriented fields (list + summary) to cut round trips, add complexity budgets with persisted queries, and implement request-scoped loaders that project only needed columns. I add an entity cache with short TTL and invalidation on writes.”

Senior:
“I run an operation registry with cost limits, cursored pagination everywhere, and composite fields for common screens. Resolvers batch keys, push aggregations to the DB, and use layered caches (memo, loader, entity, response). Federation/BFF composes subgraphs with timeouts and bulkheads. Tracing pinpoints hot fields; budgets and CI guards prevent regressions.”

‍

Evaluation Criteria

Strong answers show:

• Schema fit for user tasks (connections, filters, summaries).
  
• Governance (depth/complexity, persisted ops, page caps).
  
• N+1 control with request-scoped loaders and proper projections.
  
• Caching strategy layered across resolvers and responses with safe invalidation.
  
• Observability (per-field timing, slow-op reports) and CI checks.
  
• Safety (timeouts, breakers, auth in context) and scalable pagination.
  Red flags: table-mirroring schemas, naive offset pagination, global loader caches, no tracing, or “we will cache everything” without strategy. Bonus: federation/BFF design and composite fields for atomic screens.
  
  

Preparation Tips

• Build a demo schema with two hot lists; add cursored connections and filters.
  
• Implement DataLoader per request; prove it issues one batched query for 100 children.
  
• Add complexity and depth rules; write a test that rejects an abusive query.
  
• Create a projector that maps GraphQL selections to SQL column lists.
  
• Add entity cache with TTL and stampede control; measure hit rate.
  
• Enable Apollo/OTel tracing; build a dashboard for top slow fields and N+1 counts.
  
• Introduce persisted queries and confirm response-cache hits.
  
• Exercise federation/BFF with two services and per-subrequest timeouts; compare p95 before/after.
  
  

Real-world Context

A product catalog had a 2.8 s p95 due to N+1 on variants. Request-scoped loaders with SQL IN and column projection cut DB calls by 95% and p95 to 420 ms. A dashboard required list + totals; adding a composite field (ordersFeedWithSummary) removed two extra queries and stabilized latency under load. Response caching barely helped due to variable queries; moving to entity cache with tag invalidation improved hit rate to 70%. After adding cost limits and persisted ops, a runaway query from an A/B test was blocked automatically, protecting the cluster.

‍

Key Takeaways

• Shape the schema for tasks, not tables.
  
• Enforce depth/complexity and page caps.
  
• Eliminate N+1 with request-scoped batching and projections.
  
• Cache at multiple layers with safe invalidation.
• Trace per field and govern with budgets and persisted ops.
  
  

Practice Exercise

Scenario:
Your GraphQL API powers a marketplace feed with products, sellers, and ratings. Users report slow screens and timeouts during campaigns.

Tasks:

1. Replace offset pagination with cursor-based connections on products and include pageInfo. Enforce a max page size and add sort/filter args.
   
2. Implement request-scoped loaders for Product.seller and Product.ratings, projecting only needed columns from the selection set. Prove that fetching 100 products triggers exactly 2 batched queries, not 201.
   
3. Add complexity and depth rules: lists multiply cost by first, certain fields have higher weights. Reject or log queries above a threshold.
   
4. Create a composite field productsWithMetrics that returns items plus aggregate counts used by the UI to avoid a second round trip.
   
5. Introduce an entity cache (Redis) for Seller and Product with short TTL and stampede protection. Invalidate on writes using tag keys.
   
6. Enable per-field tracing and ship a slow-field report. Add an operation registry and persisted queries for the mobile app.
   
7. Run a load test: record DB calls, cache hit rate, and p95 latency before/after. Document improvements and any trade-offs.
   
   

Deliverable:
A report and code diff showing eliminated N+1, bounded query cost, higher cache hits, and a faster feed—plus guardrails (registry, limits) to prevent regressions.