Какие у вас нагрузки
Что проверяют
Работали ли вы с реальной нагрузкой и понимаете ли, как её измерять. Интервьюеру важны не рекорды, а то, что вы знаете цифры своего сервиса и где у него узкое место. Следом обычно спрашивают, что сломается первым, если трафик вырастет в десять раз.
Как отвечать
Опишите нагрузку в единицах, которые можно сравнить:
- поток запросов: RPS в среднем и в пике. Полезно пересчитывать самому: 10 000 запросов в минуту это около 170 RPS, для одного сервиса на Spring Boot немного;
- задержки: p95 и p99, а не среднее. Среднее прячет хвост, на который и жалуются пользователи;
- данные: объём базы, размер крупнейших таблиц, поток сообщений в Kafka;
- инфраструктура: число инстансов, память JVM, сборщик мусора (G1 по умолчанию, ZGC для коротких пауз);
- узкие места: пул соединений к базе (у HikariCP по умолчанию 10), медленные запросы, блокировки, паузы GC, внешние API.
Затем расскажите один эпизод: как нашли проблему (метрики через Micrometer в Prometheus и Grafana, профилирование через async-profiler или JFR), что поменяли и какие цифры получили. Про нагрузочное тестирование назовите инструмент, JMeter, Gatling или k6, и профиль нагрузки, который моделировали.
Если серьёзной нагрузки не было, так и скажите: «пик около 50 RPS, узким местом была база». Потом покажите, как рассуждали бы при росте: кэш, индексы, горизонтальное масштабирование, виртуальные потоки Java 21 для блокирующего ввода-вывода, очередь для тяжёлых операций. Свои цифры и примеры обязательны. Честные скромные данные с пониманием механики звучат сильнее громких, которые вы не можете объяснить.
Где спотыкаются
Называют цифры без единиц и периода: про «десять тысяч запросов» непонятно, за секунду, минуту или сутки.
Выдают нагрузку всей системы за нагрузку своего сервиса. Уточняющий вопрос про конкретный компонент быстро это вскрывает.
Говорят про ускорение «на 40%», не зная, какую метрику сравнивали и как мерили. Без перцентиля, окружения и методики эта цифра ничего не значит.