Response Batching

At a busy restaurant, a good waiter does not bring each dish one at a time, running back and forth eight times for a table of four with appetizers and mains. They load up a tray and bring multiple plates in one trip.

Response batching works the same way on the server side. Instead of sending individual responses for each piece of data, the server collects multiple results and sends them in a single response. This matters most when a client needs data from multiple sources or endpoints. The server fetches everything, bundles it, and returns one payload.

GraphQL is response batching baked into the query language. A single GraphQL query can request data that would require five REST calls. The server resolves all fields, batches the results, and returns one response. Facebook designed GraphQL specifically to solve the problem of mobile apps making dozens of individual REST calls over slow 3G networks. At the time, the Facebook iOS app was making 15 to 20 REST calls per screen render. Each of those calls carried its own TCP overhead, its own authentication check, its own serialization cost. GraphQL collapsed them into one.

Shopify's Storefront API processes around 80,000 batched queries per second during flash sales, with each query pulling product, inventory, and pricing data that would otherwise require three separate REST calls.

Without response batching (the N+1 problem):

GET /api/users/123       -> { name: "Roni", teamId: "T1" }
GET /api/teams/T1        -> { name: "Engineering" }
GET /api/users/123/posts -> [{ title: "..." }, ...]
GET /api/users/123/badges -> [{ name: "..." }, ...]
// 4 round trips, 4 auth checks, 4 TCP payloads

With response batching (server aggregates):

GET /api/users/123?include=team,posts,badges
-> {
  name: "Roni",
  team: { name: "Engineering" },
  posts: [{ title: "..." }],
  badges: [{ name: "..." }]
  }
// 1 round trip, 1 auth check, 1 TCP payload

Three implementation approaches dominate production systems:

Field inclusion (sparse fieldsets). Let the client specify which related resources to include: ?include=team,posts&fields=name,email. The server fetches all requested data in parallel and returns one bundled response. JSON:API, Stripe's expand parameter, and Shopify's REST API all use this pattern. Stripe lets you ?expand[]=customer&expand[]=payment_method to pull related objects into a single charge response.

DataLoader pattern (server-side). Facebook's DataLoader collects individual database requests within a single tick of the event loop and batches them into one query. Fifty individual getUserById calls become one SELECT * FROM users WHERE id IN (...) query. This is the standard approach in GraphQL resolvers. Without it, a query for 20 posts with authors would fire 20 separate SELECT * FROM users WHERE id = ? queries. DataLoader coalesces them into a single query with 20 IDs.

API aggregation layer. A dedicated service that calls multiple backend APIs in parallel, combines the results, and returns a single response. This is the Backend-for-Frontend (BFF) pattern. Netflix runs a separate BFF for each client type (iOS, Android, TV, web), each one tailored to that platform's screen shape and data needs. The iOS BFF for the home screen pulls from 6 different microservices and returns one payload shaped exactly for the iOS home screen layout.