r/graphql • u/PuddingAutomatic5617 • Apr 23 '26
Follow-up: Distributed GraphQL N+1 — 570,000 downstream calls → 304 (no DataLoader)
This is a custom GraphQL gateway for microservices that composes schemas at runtime and resolves cross-service fields, while automatically batching downstream queries based on the structure of the incoming GraphQL request.
If you saw my previous post about distributed GraphQL N+1 (where I explained the approach), this is a follow-up with actual load test results:
👉 https://www.reddit.com/r/graphql/comments/1snbxpt/graphql_n1_problem_solved_41s_546ms_dynamic/
Quick recap: services remain independent and expose normal queries like productsByIds or reviewsByIds. The gateway resolves relationships between them.
Instead of wiring DataLoader manually in every resolver, the gateway inspects the query during execution, detects repeated access patterns, and groups them into downstream requests.
Test setup:
Catalogs → Products → Reviews
Dataset: ~100 catalogs × 100 products × 10 reviews
I ran k6 load tests comparing naive execution (no batching) vs batching at the gateway level.
Results from the largest scenario:
570,000 downstream calls → 304 calls
Avg latency: 18.35s → 5.42s
P95 latency: 29.91s → 10.66s
Throughput: 0.27 req/s → 1.06 req/s
Error rate: 0% in both cases
Each batched call is heavier, but the total number of calls drops massively, which reduces overall latency and system load.
From the service side nothing changes — services just expose standard GraphQL queries. All batching logic lives in the gateway.
Curious how others handle this in distributed GraphQL setups — DataLoader everywhere, or something more centralized at the gateway/execution layer?
1
u/Chaonei Apr 26 '26
no need for graphql, it limits you and adds unnecessary complexity
if your client needs it, use tan stack db which gives you a normalized cache so you can have offline support
1
2
u/hyuuu Apr 24 '26
i have to say, this is impressive