Кросс-протокольный N+1: HTTP fan-out и Redis MGET

REST endpoint собирает профиль пользователя, вызывая 8 downstream микросервисов — один для preferences, один для posts, один для notifications, один для billing и ещё четыре. Каждый вызов занимает 30 мс. Итоговая latency: 240 мс. Ни один вызов не медленный. Проблема в том, что все они серийные.

Форма появляется в каждом протоколе

Паттерн N+1 — не проблема только для баз данных. Везде, где программа делает множество небольших round-trip’ов вместо одной более крупной операции, применяется тот же множитель стоимости.

Overhead на round-trip различается по протоколу и расстоянию: Postgres на localhost ~0.5 мс, Redis на том же хосте ~0.1 мс, HTTP intra-DC ~2 мс, HTTP cross-region ~50 мс. Но математика та же: N вызовов × overhead на вызов = серийное wall-clock доминирует.

HTTP fan-out: вызывать сервисы параллельно

Profile aggregator, вызывающий 8 сервисов серийно:

// Серийно — платит 8 × RTT последовательно:
const user = await userService.get(userId);
const posts = await postsService.get(userId);
const notifs = await notifService.get(userId);
// ... ещё 5 вызовов
// Итого: ~240 мс при 30 мс на вызов

// Параллельно — wall-clock = max(latencies):
const [user, posts, notifs, ...rest] = await Promise.all([
  userService.get(userId),
  postsService.get(userId),
  notifService.get(userId),
  // ... ещё 5
]);
// Итого: ~35 мс (самый медленный вызов + небольшой coordination overhead)

Promise.all (Node/JS), errgroup.Wait (Go), CompletableFuture.allOf (Java), asyncio.gather (Python) — паттерн идентичен во всех runtime.

Wall-clock меняется с sum(latencies) до max(latencies).

Для 8 вызовов по 30 мс: 240 мс серийно против 35 мс параллельно — улучшение в 7 раз с одним структурным изменением.

Redis: MGET вместо GET в цикле

Кэш-слой, получающий 100 элементов по одному:

# 100 round-trip'ов — GET в цикле:
items = keys.map { |k| redis.get(k) }

# Один round-trip — MGET:
items = redis.mget(*keys)

# Или pipeline для условной логики на элемент:
results = redis.pipelined { keys.each { |k| redis.get(k) } }

Redis RTT на том же хосте обычно 0.1–0.5 мс. Цикл из 100 GET’ов стоит 10–50 мс. Один MGET стоит 0.5–2 мс. Фикс — одна команда.

Для условной логики (когда нужно действовать по каждому результату перед следующим получением), используйте pipelining вместо MGET: отправить все команды сразу, получить все ответы сразу.

Зависимости вызовов сервисов — DAG-dispatch

Некоторые вызовы сервисов зависят от других. Цепочку зависимостей нельзя полностью распараллелить:

// Последовательная зависимость: посты нужны userId сначала
const userId = await authService.resolveToken(token);
// Затем эти можно запустить параллельно:
const [posts, notifs, billing] = await Promise.all([
  postsService.get(userId),
  notifService.get(userId),
  billingService.get(userId),
]);

Структура — DAG (directed acyclic graph). Сервисы без зависимостей стартуют сразу; сервисы, зависящие от более ранних результатов, ждут только своих прямых родителей. Большинство fan-out API имеют мелкие DAG’и (1–2 уровня зависимостей). Полностью серийные цепочки вызовов обычно случайны и могут быть разобраны трассировкой реальных зависимостей.

Governance: предотвращение возврата серийного fan-out

Статический анализ может поймать паттерн до выкатки:

• JavaScript/Node: правило линтера, отклоняющее await внутри for-цикла над вызовами сервисов.
• Пункт code review checklist: “вызывает ли эта функция удалённый сервис N раз в цикле? Если да — сигнализировать.”
• Observability: панель дашборда по сервису, показывающая “fan-out factor” (downstream вызовов на входящий запрос). Алерт при росте.
• Load-test assertions: trace assertions в нагрузочных тестах могут провалить PR’ы, увеличивающие fan-out сверх порога.