Приходилось ли работать с нагрузками на сервис и как с ними справлялись
Что проверяют
Умеете ли вы искать узкое место измерением, а не перебором популярных средств. Ответ «поставили кэш и подняли ещё несколько инстансов» показывает, что причину вы не нашли, а симптом залили железом.
Как отвечать
Начните с цифр, на которые опирались: сколько запросов в секунду, ровная нагрузка или пики, какие требования к задержке. Дальше порядок действий:
- метрики: задержка по p95 и p99, доля ошибок, насыщение пулов и очередей;
- трассировка запроса по сервисам, чтобы увидеть, где именно уходит время;
- профиль JVM и логи сборщика мусора, если подозрение на само приложение.
Типичные находки в Java-сервисе: N+1 запросов через ORM, отсутствующий индекс, пул соединений меньше числа рабочих потоков, обращение к внешнему сервису без таймаута, ленивая инициализация в горячем пути, сериализация крупных ответов.
Дальше меры по возрастанию цены: починить запросы и индексы, убрать лишние походы в базу, добавить кэш с понятной инвалидацией, перейти на пакетную обработку, и только потом масштабироваться горизонтально, если сервис действительно без состояния. Отдельно назовите защиту от перегрузки: таймауты, ограничение параллелизма, размыкатель цепи, быстрый отказ вместо очереди на минуту.
Где спотыкаются
Оперируют средним временем ответа. Среднее прячет хвост: часть пользователей ждёт секунды, а число на дашборде остаётся приличным. Говорить надо в перцентилях, и интервьюер обычно ждёт именно этого слова.
Второе: называют переход на микросервисы способом справиться с нагрузкой. Разделение добавляет сетевые вызовы и сериализацию, а медленный запрос к базе после переезда останется ровно таким же медленным.
Третье: нагрузочный тест на пустой базе и без прогрева. Горячий код ещё не скомпилирован, планировщик базы работает на других объёмах данных, и результаты такого стенда на прод не переносятся.