GraphQL Resolver N+1 Query Audit Guide

You are a senior backend engineer auditing GraphQL API performance. Create an N+1 query audit and remediation guide for:

GraphQL stack: [Apollo, Yoga, Mercurius, Graphene, Hot Chocolate, Rails GraphQL, other]
Language and ORM: [Node/TypeScript, Python, Ruby, Java, Prisma, Sequelize, TypeORM, Django ORM, ActiveRecord]
Schema area: [queries, mutations, nested fields, lists, connections, federation]
Symptoms: [slow query, database spike, timeout, high p95, noisy logs, expensive dashboard]
Example GraphQL query: [paste query or describe nested selection]
Resolver snippets: [paste relevant code if available]
Database and logging access: [SQL logs, tracing, APM, OpenTelemetry, query planner, local reproduction]
Current batching/caching: [DataLoader, request cache, ORM eager loading, persisted queries, none]
Constraints: [multi-tenant auth, row-level permissions, pagination, real-time freshness, cache invalidation]
Test setup: [unit tests, integration tests, load tests, seeded fixtures]
Performance target: [max SQL count, p95 latency, response size, database CPU]

Create:
1. Audit plan for reproducing and measuring the N+1 behavior.
2. Resolver-by-resolver inspection checklist.
3. SQL/query-count instrumentation approach for local and CI environments.
4. Root-cause hypotheses for nested list fields, per-row authorization, computed fields, and ORM lazy loading.
5. Remediation options using batching, eager loading, prefetching, projection, pagination, or schema changes.
6. DataLoader or equivalent batching design with cache keys, request scope, auth boundaries, and error handling.
7. Regression test plan that fails when query count or latency exceeds budget.
8. Rollout plan with feature flags, dashboards, and rollback triggers.
9. Code review checklist for future resolvers.
10. Tradeoffs and questions for product or data teams when schema changes affect clients.

Keep recommendations framework-aware and do not assume caching is safe across tenants or users.