Batching
When to Use Batching
In Practice
linger.ms waits up to N ms to fill a batch. DynamoDB's BatchWriteItem can do 25 puts per call. GraphQL's DataLoader pattern is request-scoped batching.How Batching Comes Up in Interviews
Scenario
Your GraphQL resolver fires N individual SELECTs against the DB for one request, the classic N+1 problem. DataLoader fixes it by coalescing all the .load() calls within a tick into one query. What's the general technique?
Batching coalesces many small operations into one large one to amortize fixed per-request overhead. Debounce delays an action until a pause, different goal.
Batching coalesces many small operations into one bigger one to amortize per-operation overhead: fixed network round-trip cost, query parsing, connection handshakes. DataLoader is the canonical implementation: within a single tick of the event loop, all the .load(id) calls get queued, then on the next tick they're consolidated into one SELECT ... WHERE id IN (...). Kafka producers do the same thing with linger.ms (wait up to N ms to fill a batch); DynamoDB exposes BatchWriteItem for up to 25 puts per call; S3's MultipartUpload is a batching variant. The tradeoff is latency: you wait for the batch to fill before sending, so per-request latency increases for throughput gains.