Какова нагрузка системы в запросах в секунду?

Что проверяют

Мыслите ли вы числами. Интервьюер хочет понять, знаете ли вы фактическую нагрузку своего сервиса, откуда взялась цифра и что она означает вместе с латентностью. Дальше идёт продолжение: «а сколько выдержит» и «где упрётся первым».

Как отвечать

Сначала назовите свои числа честно: средний RPS, пиковый, соотношение пика к среднему, распределение по ручкам. «Около 300 запросов в секунду в среднем и до 1200 в вечерний пик, 80% это чтение каталога» звучит иначе, чем «высоконагруженный сервис».

Дальше покажите, что цифра не живёт отдельно:

• связь с латентностью: по закону Литтла среднее число запросов в обработке равно RPS, умноженному на среднее время ответа. 1000 RPS при 200 мс это 200 одновременных запросов, и это уже требование к пулам и лимитам;
• что мерить кроме RPS: p50, p95, p99, доля ошибок, насыщение ресурсов. Метод RED для запросов, USE для ресурсов. Средняя латентность бесполезна;
• откуда цифры: гистограммы Prometheus через promhttp, трассировки OpenTelemetry, нагрузочные тесты k6, wrk, для gRPC ghz. Генератор должен держать заданную скорость независимо от ответов сервиса, иначе получите заниженную латентность из-за coordinated omission;
• где обычно упирается Go-сервис: не в горутины, а в пул соединений к базе (SetMaxOpenConns), внешние вызовы без таймаута, конкуренцию на мьютексах, аллокации и работу сборщика мусора. Смотрят через pprof и runtime/metrics;
• контейнеры: начиная с Go 1.25 рантайм учитывает лимит CPU в cgroup и подстраивает GOMAXPROCS сам, на более старых версиях ставят automaxprocs. Память ограничивают через GOMEMLIMIT.

Закончите планированием: считают не на текущий пик, а на пик с запасом, и заранее решают, что деградирует первым: кэш, лимиты, отключение необязательного.

Где спотыкаются

Называют RPS без латентности и доли ошибок. Сервис может держать 5000 запросов в секунду с p99 в десять секунд, и это нерабочее состояние.

Стреляют с ноутбука по Wi-Fi в один поток и меряют генератор, а не сервис.

Считают, что горутины сами решают вопрос масштабирования, и не могут назвать реальный предел: соединения к базе, файловые дескрипторы, пропускная способность внешнего API.