Как обеспечить время ответа backend-сервиса менее 100 мс при высоком RPS?

Question

Сначала нужно “вписаться” в бюджет времени: сеть, сериализация, бизнес-логика, БД и внешние вызовы. Для <100 мс обычно убирают тяжёлые операции из запроса: предрасчёт, кеш, асинхронная обработка. Затем ограничивают вариативность: таймауты, лимиты, отказ от лишних сетевых прыжков. Обязательно оптимизируют доступ к данным (индексы, короткие запросы, батчи) и следят за p95/p99, а не только за средним временем. Без наблюдаемости и нагрузочного теста это не удержать.

YeaHub · Accepted Answer

Откуда берётся 100 мс100 мс — это общий бюджет на весь путь: клиент → сеть → сервис → зависимости → ответ. Обычно “съедают” время именно зависимости, поэтому быстрый сервис — это сервис с минимальным количеством непредсказуемых вызовов.1) Бюджет времени и цель по перцентилямНужно сразу определить:целевой перцентиль (например, p95 < 100 мс, p99 < 200 мс)максимальное число сетевых hops (чем меньше, тем лучше)Определение: Percentile (p95/p99) — время, быстрее которого укладывается 95%/99% запросов; это главный показатель “хвостовой” задержки.2) Сократить работу в запросеТиповые приёмы:предрасчёт и хранение готовых результатовкэширование (частей ответа или всего ответа)перенос тяжёлых операций в фон (очередь/воркеры)Если данные “почти всегда уникальны”, кэш может быть не по полному ответу, а по его частям:справочники/права/настройкиданные профилярезультаты дорогих вычислений, которые переиспользуются между запросами3) Оптимизировать доступ к даннымС БД важно:короткие запросы (без лишних join/scan)индексы под реальные фильтрыограничение объёма выборки (пагинация, лимиты)пул соединений адекватного размера4) Ограничить параллелизм и защитить зависимостиПод высоким RPS легко “убить” БД лавиной параллельных операций.Практика:лимит параллельных запросов к БД/внешним сервисамтаймауты на каждый вызовдеградация (лучше частичный ответ, чем 500)Пример таймаута и отмены через context:ctx, cancel := context.WithTimeout(r.Context(), 80*time.Millisecond)
defer cancel()

// db.QueryContext(ctx, ...)
5) Уменьшить накладные расходы в GoВ Go типичные источники потерь:лишние аллокации на горячем путибольшие JSON payload и частая сериализацияслишком подробное логирование на каждый запросПрактика:профилировать pprof (CPU/heap)избегать лишних преобразований структураккуратно с middleware, которые делают много работы6) Наблюдаемость и нагрузочные тестыЧтобы удерживать SLA, измеряйте:latency p50/p95/p99долю таймаутов и ретраевlatency по каждой зависимостинасыщение пулов (goroutines, DB pool)ВыводСтабильные <100 мс при высоком RPS достигаются не “быстрым кодом”, а архитектурой быстрого пути: минимум зависимостей в запросе, предрасчёт/кэш, строгие таймауты и лимиты, плюс контроль p95/p99 и постоянное профилирование.