Что улучшило производительность сервиса уведомлений
Что проверяют
Вопрос про конкретную систему, но проверяют метод. Интервьюеру важно, с чего вы начали, чем мерили, что оказалось узким местом и как убедились, что стало лучше. Ответ «добавили кэш и увеличили пул потоков» показывает, что кандидат угадывал, а не измерял.
Как отвечать
Держите порядок: симптом, измерение, гипотеза, изменение, повторный замер.
Симптом формулируется метрикой, а не ощущением: выросло время доставки по верхним перцентилям, копится очередь, растёт доля повторов. Дальше профиль, трассировка запроса и метрики пулов.
Типичные находки в сервисе уведомлений на Java:
- поход в базу за настройками и шаблоном на каждое сообщение. Лечится кэшем с коротким временем жизни и выборкой пачкой вместо запроса на строку;
- синхронный вызов внешнего провайдера на каждое уведомление. Пакетная отправка и переиспользование соединений через пул дают больше всего;
- отправка внутри транзакции и внутри пользовательского запроса. Выносится в очередь, надёжность через журнал исходящих сообщений;
- пул потоков, целиком стоящий на сетевых ожиданиях. Помогают разделение пулов по типам работы, таймауты и ограничение очереди вместо безграничной;
- аллокации и сборка строк для логов на горячем пути, отсюда паузы сборщика мусора.
Заканчивайте критерием: сравнение по перцентилям на одинаковом профиле нагрузки, иначе это не улучшение, а совпадение.
Где спотыкаются
Отвечают списком технологий вместо разбора. Kafka, кэш, виртуальные потоки названы, а что именно было узким местом, не сказано, и непонятно, почему помогло.
Доказывают улучшение средним временем. Среднее прячет хвосты, а жалобы приходят именно с хвостов: смотреть надо верхние перцентили и максимум.
Путают пропускную способность с задержкой. Увеличили пачки и число обработчиков, суммарно шлём больше, а время доставки отдельного уведомления выросло, потому что сообщение ждёт наполнения пакета.