Increased tail latency under concurrent load with tRPC httpBatchLink

When using tRPC's httpBatchLink with the default 1 ms batchWindow, request latency remains low for isolated calls but shows a noticeable increase in the 95th‑plus percentile as concurrent request volume rises.

The batchWindow is a fixed timer that does not adapt to request arrival patterns, and any synchronous work in middleware or context creation can delay the event‑loop tick that triggers the batch flush, making it hard to isolate whether the observed tail latency stems from the batching window itself, event‑loop saturation, or a combination of both. Without built‑in metrics for batch fill rate or per‑request queue time, diagnosing the root cause relies on external instrumentation.

What batchWindow value reduces the observed tail latency for a given concurrency level? How does synchronous middleware amplify batch flush jitter under load? Is there a lightweight way to expose per‑request enqueue time without adding custom middleware?