Есть ли опыт построения нагруженных систем
Что проверяют
Есть ли за словами «высокая нагрузка» реальные цифры и решения, которые принимали именно вы. Интервьюеру важно понять масштаб и ваш личный вклад. Следом почти всегда спрашивают, где было узкое место, как вы его нашли и чем подтвердили, что стало лучше.
Как отвечать
Нужна история из вашего опыта со своими цифрами. Каркас такой:
- масштаб: RPS в пике, объём данных, требование к задержке (p95, p99), число инстансов. «10 000 запросов в минуту» это меньше 200 RPS, для ASP.NET Core на одном сервере это обычный режим, а не хайлоад;
- узкое место: во что упирались. База, пул потоков, внешний API, сборщик мусора;
- диагностика: чем искали.
dotnet-countersиdotnet-trace, трассировка через OpenTelemetry, профилировщик, медленные запросы в базе; - решение и компромисс: например, убрали
.Resultи.Wait()в синхронных обёртках над асинхронным кодом, из-за которых голодал пул потоков. ПеревелиHttpClientнаIHttpClientFactory, закрыли N+1 в EF Core и включилиAsNoTracking()на чтении, горячий запрос переписали на Dapper, тяжёлую обработку вынесли в очередь через RabbitMQ или Kafka, добавили кэш в Redis и договорились, насколько данные могут устаревать; - проверка: нагрузочный тест в k6, JMeter или NBomber до и после, метрики на проде.
Если опыта с большой нагрузкой не было, так и скажите и назовите свой реальный максимум. Затем покажите, как бы действовали: сначала измерить и найти узкое место, потом кэш, асинхронность, горизонтальное масштабирование за балансировщиком. Честное «до 300 RPS, но вот как мы разбирали деградацию» звучит сильнее выдуманных миллионов.
Где спотыкаются
Перечисляют технологии без цифр: «микросервисы, Redis, Kafka». Без масштаба и результата непонятно, была ли нагрузка вообще.
Рассказывают о решениях всей команды от первого лица, а на уточняющем вопросе про настройку пула соединений или ретраи теряются.
Называют результат без метода: «ускорили на 30%». Спросят, как мерили, на каком перцентиле и под какой нагрузкой, и ответ должен быть готов.