Cross-protocol N+1: HTTP fan-out and Redis MGET

The shape appears in every protocol

The N+1 pattern is not a database-only problem. Anywhere a program makes multiple small round-trips where one larger operation would suffice, the same cost multiplier applies.

The per-round-trip overhead differs by protocol and distance: Postgres on localhost ~0.5 ms, Redis same-host ~0.1 ms, HTTP intra-DC ~2 ms, HTTP cross-region ~50 ms. But the math is the same: N calls × per-call overhead = serial wall-clock dominates.

HTTP fan-out: call services in parallel

A profile aggregator calling 8 services serially:

// Serial — pays 8 × RTT in sequence:
const user = await userService.get(userId);
const posts = await postsService.get(userId);
const notifs = await notifService.get(userId);
// ... 5 more calls
// Total: ~240 ms if each call is 30 ms

// Parallel — wall-clock = max(latencies):
const [user, posts, notifs, ...rest] = await Promise.all([
  userService.get(userId),
  postsService.get(userId),
  notifService.get(userId),
  // ... 5 more
]);
// Total: ~35 ms (slowest call + small coordination overhead)

Promise.all (Node/JS), errgroup.Wait (Go), CompletableFuture.allOf (Java), asyncio.gather (Python) — the pattern is identical across runtimes.

The wall-clock changes from sum(latencies) to max(latencies).

For 8 calls at 30 ms each: 240 ms serial vs 35 ms parallel — a 7× improvement with one structural change.

Redis: MGET instead of GET in a loop

A cache layer that fetches 100 items one by one:

# 100 round-trips — GET in a loop:
items = keys.map { |k| redis.get(k) }

# One round-trip — MGET:
items = redis.mget(*keys)

# Or pipeline for conditional logic per item:
results = redis.pipelined { keys.each { |k| redis.get(k) } }

Redis RTT on the same host is typically 0.1–0.5 ms. A loop of 100 GETs costs 10–50 ms. One MGET costs 0.5–2 ms. The fix is a single command.

For conditional logic (where you need to act on each result before deciding to fetch the next), use pipelining instead of MGET: send all commands at once, receive all responses at once.

Service call dependencies — DAG dispatch

Some service calls depend on others. You cannot fully parallelize a dependency chain:

// Sequential dependency: posts need userId first
const userId = await authService.resolveToken(token);
// Then these can all run in parallel:
const [posts, notifs, billing] = await Promise.all([
  postsService.get(userId),
  notifService.get(userId),
  billingService.get(userId),
]);

The structure is a DAG (directed acyclic graph). Services with no dependencies start immediately; services that depend on earlier results wait only for their direct parents. Most fan-out APIs have shallow DAGs (1–2 dependency levels). Fully serial call chains are usually accidental and can be unwound by tracing the actual dependency relationships.

Governance: preventing serial fan-out from returning

Static analysis can catch the pattern before it ships:

• JavaScript/Node: lint rule rejecting await inside a for loop over service calls.
• Code review checklist item: “does this function call a remote service N times in a loop? If yes, flag it.”
• Observability: per-service dashboard panel showing “fan-out factor” (downstream calls per inbound request). Alert when it grows.
• Load-test assertions: trace assertions in load tests can fail PRs that increase fan-out beyond a threshold.