Power of Two Choices works because sampling beats omniscience at scale. But sometimes you genuinely have the queue depths — a load balancer with health checks, an in-process worker pool, a database router with connection telemetry. In those cases, Join the Shortest Queue (JSQ) is the optimal policy: send every request to the backend with the fewest in-flight requests. The question is when you can afford it.

The cost of JSQ is information. Classic JSQ requires querying every backend on every dispatch. For N backends and R requests per second, that's N × R state lookups per second. With 1,000 backends and 50,000 RPS, you're doing 50 million reads just to make routing decisions. That's why hyperscalers fall back to Power of Two — the asymptotic performance is nearly identical, the overhead is constant.

But for small N, JSQ wins decisively. Rule of thumb: if N ≤ ~50 and queue state is locally available (shared memory, atomic counters, or a single coordinator), use JSQ. Above that, the variance reduction from full information stops paying for itself.

Concrete example: A Node.js process running a worker pool of 8 threads handling CPU-bound image transforms. Each worker exposes an atomic inFlightCount. When a request arrives, the dispatcher scans all 8 counters (a nanosecond operation), picks the minimum, and increments atomically. Tail latency drops 30-40% compared to round-robin, because round-robin happily routes requests to a thread already stuck on a slow 50MB TIFF while another thread sits idle.

The variants matter:

• JSQ-d: Sample d backends, pick the shortest. d=2 is Power of Two. d=N is full JSQ. Pick d based on how expensive your "ask" operation is.
• JSQ with idle queue: Maintain a separate list of idle backends. If any are idle, dispatch there first. Only fall back to length comparison when all are busy. Cuts the read overhead in the common low-load case.
• Weighted JSQ: Divide queue length by backend capacity. Essential when backends are heterogeneous — a 16-core box with 10 pending should beat a 4-core box with 5 pending.

The trap: Stale queue depths. If your dispatcher caches counts for even 100ms under high load, you'll herd — every dispatcher sees the same "shortest" backend and stampedes it. Either read fresh on every dispatch (cheap when N is small) or use Power of Two with truly random sampling. Cached state plus deterministic selection is the worst combination.

JSQ isn't a replacement for Power of Two — it's the right answer at a different scale. Know which regime you're in.