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

Нагрузка должна быть частью задачи, а не финальным вопросом

Сервис может начать отдавать 502 не из-за одной «медленной функции», а потому, что очередь запросов заполнилась, пул соединений закончился, ретраи умножили трафик, а память ушла на буферы. Поэтому техническое интервью под нагрузкой проверяет не способность кандидата назвать Redis или Kafka, а умение предсказать цепочку отказов и остановить её до каскадного сбоя.

Ниже — методика для интервью на backend- и platform-роли. Она подходит для сервисов на разных языках и фреймворках: конкретную версию нужно зафиксировать в условии. Ориентир для примеров по инфраструктуре — PostgreSQL 16 и Redis 7.2; если в вашей системе стоят другие версии, проверяйте поведение на том же стенде, а не переносите выводы автоматически.

Хороший ответ под нагрузкой начинается не с «добавим кэш», а с вопроса: какая очередь заполнится первой и какой сигнал покажет это оператору.

Как сформулировать задачу

Дайте кандидату небольшой, но правдоподобный сценарий. Например: API возвращает карточку товара, проверяет остаток в PostgreSQL, получает цену из отдельного сервиса и пишет событие в брокер. Базовая нагрузка — 100 запросов в секунду, затем она растёт до 800. 95-й перцентиль ответа должен оставаться ниже 300 мс, а устаревшая цена хуже ошибки: бизнес не готов показывать неверную стоимость.

В условии сразу укажите границы. Сколько экземпляров сервиса работает, где находится база, сколько соединений разрешено, какие операции синхронные, можно ли отдавать устаревшие данные. Если эти параметры скрыть, интервью проверит не инженерное мышление, а способность угадывать вводные.

Попросите кандидата не только предложить решение, но и проговорить порядок событий:

1. Назвать целевые показатели: пропускную способность, задержку, долю ошибок, потребление памяти и насыщение зависимостей.
2. Нарисовать путь одного запроса от балансировщика до базы и внешних сервисов.
3. Указать первый ограниченный ресурс и объяснить, по какому метрику это станет видно.
4. Предложить безопасное поведение при исчерпании ресурса: отказ, деградация, ограничение очереди или возврат кэша.
5. Назвать тест, который отличит гипотезу от догадки.

После каждого шага задавайте один и тот же вопрос: «Что мы увидим в проде, если вы правы?» Ответ должен приводить к наблюдаемому сигналу, а не к общему слову «система замедлится».

Какие вводные нельзя оставлять за кадром

• Размер ответа и долю чтений и записей.
• Пиковую и постоянную нагрузку, а также длительность пика.
• Таймауты каждого внешнего вызова и правила повторных попыток.
• Размер пула соединений приложения и лимиты базы данных.
• Допустимость потери события, повторной обработки и устаревших данных.

Перцентиль — значение, ниже которого укладывается заданная доля запросов. 95-й перцентиль в 300 мс означает, что 95% измеренных запросов быстрее этого порога, но самые медленные 5% могут быть значительно хуже среднего.

Четыре режима интервью и их цена

Один формат редко показывает реальное поведение инженера. Открытый вопрос даёт простор для рассуждений, но позволяет спрятаться за общими словами. Лучше выбрать режим под уровень позиции и ограниченное время.

Что обычно ломается первым

1. Очередь без верхней границы

Если обработчик медленнее входящего потока, запросы начинают ждать. Очередь временно скрывает проблему, но увеличивает задержку и расход памяти. Когда кандидат предлагает «поставить очередь», спросите о максимальной длине, времени жизни элемента и поведении при переполнении.

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

2. Пул соединений

Приложение может масштабироваться горизонтально, а база — нет. Если каждый из 20 экземпляров откроет по 100 соединений, лимит будет исчерпан ещё до роста полезной работы. Кандидат должен связать размер пула с числом экземпляров и лимитом базы, а не называть «увеличить pool» универсальным лечением.

Отдельно спросите, что произойдёт при медленном запросе. Если соединение удерживается на время внешнего HTTP-вызова, небольшая задержка зависимости превращается в нехватку соединений с базой.

3. Таймауты и повторные попытки

Ретрай не создаёт дополнительную ёмкость. При сбое внешнего сервиса он может кратно увеличить число вызовов и превратить частичную деградацию в перегрузку. Ищите в ответе ограничение числа попыток, экспоненциальную задержку, случайное рассеивание задержек и общий дедлайн запроса.

Попросите кандидата объяснить идемпотентность операции. Повторный запрос на чтение обычно безопаснее повторной оплаты или публикации события. Если это не учтено, технически корректный механизм ретраев создаст дубликаты и финансовый инцидент.

4. Память и размер ответа

Самый быстрый запрос может быть опасным, если он собирает в памяти большой список или загружает полный объект вместо страниц. На резком росте размера ответа сначала увеличится давление на сборщик мусора или аллокатор, затем появятся длинные паузы и перезапуски.

Проверяйте, знает ли кандидат, где измерять: RSS процесса, heap, время пауз, размер сериализованного ответа и число элементов в одном запросе. Формулировка «добавим больше памяти» без лимита на входные данные — не план, а перенос отказа.

5. Горячие ключи и блокировки

Кэш помогает не всегда. Один популярный ключ может стать точкой конкуренции при одновременном истечении срока хранения. В базе аналогичную роль играет строка или индекс, который обновляют тысячи транзакций.

Спросите, как кандидат отличит нехватку CPU от ожидания блокировки. Нужны конкретные наблюдения: распределение времени запроса по этапам, активные блокировки, частота попаданий в кэш, нагрузка на диск и время ожидания потока.

Как оценивать ответ, а не набор терминов

Разделите оценку на четыре независимых навыка. Это снижает риск нанять человека, который знает названия паттернов, но не умеет выбрать безопасный компромисс.

• Модель нагрузки. Кандидат переводит запросы в секунду в работу зависимостей: чтения, записи, сетевые вызовы и объём данных.
• Порядок отказа. Он называет не только все возможные проблемы, но и первую, вторую и третью по вероятности.
• Наблюдаемость. Для каждого предположения есть метрика, лог, трассировка или воспроизводимый тест.
• Безопасная деградация. Ответ описывает, что получит пользователь, когда ресурс исчерпан, и как система вернётся в норму.

Хороший маркер уровня — способность пересмотреть решение. Если после сообщения «внешний сервис отвечает 2 секунды вместо 50 мс» кандидат меняет только число таймаута, но не анализирует занятые потоки, очереди и повторные вызовы, он видит параметр, а не систему.

Граничные случаи и где методика ломается

Интервьюер легко создаёт искусственную задачу, где правильный ответ известен заранее. Это снижает качество сигнала. Не подсказывайте кандидату, что проблема именно в базе, и не добавляйте десять зависимостей ради драматургии. Один сценарий должен иметь несколько правдоподобных причин и возможность проверить их измерением.

Отдельная ловушка — смешать разные профили нагрузки. 800 коротких чтений и 80 тяжёлых отчётов — не одна и та же нагрузка. Уточняйте размер запроса, распределение ключей, долю ошибок и длительность теста. Короткий всплеск может переживаться иначе, чем часовая работа на уровне 70% от предела.

Нельзя делать вывод о производительности по локальному ноутбуку кандидата. На стенде фиксируйте CPU, память, сетевую задержку, объём данных, число экземпляров и параллельность. Если реальных замеров нет, так и записывайте: кандидат предложил гипотезу, но не подтвердил её экспериментом.

Формулировки для интервьюера

• «Какой ресурс закончится первым при удвоении нагрузки и почему?»
• «Какая метрика изменится раньше, чем вырастет доля 5xx?»
• «Что произойдёт, если зависимость будет отвечать в 20 раз медленнее?»
• «Какая часть вашего решения создаёт очередь?»
• «Что вы ограничите, чтобы отказ не перешёл на соседние сервисы?»

Что делать после интервью

Сохраните не только итоговый балл, но и карту рассуждений: какие вводные кандидат запросил, какие гипотезы выдвинул и какие сигналы предложил измерять. Затем возьмите один реальный сервис и воспроизведите его критический путь на стенде с данными, близкими к боевым.

Начните с базовой линии: пропускная способность, p50 и p95 задержки, доля ошибок, загрузка CPU и памяти, ожидание пула соединений, глубина очередей. После этого увеличивайте нагрузку ступенями и фиксируйте не только момент отказа, но и первый изменившийся показатель. Инвалидация кэша и детальный выбор брокера — отдельные темы; здесь важнее научиться видеть порядок отказов и цену каждой защиты.