Работали ли вы с Spring WebFlux

Что проверяют

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

Как отвечать

Опишите суть: WebFlux это неблокирующий веб-слой на Project Reactor, работающий поверх Netty или сервлет-контейнера с асинхронным вводом-выводом. Возвращаемые типы Mono для одного значения и Flux для потока.

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

Условие работоспособности: неблокирующая цепочка целиком. Один блокирующий вызов на потоке цикла событий останавливает обслуживание всех соединений этого потока. Значит, либо реактивный драйвер базы, либо явный вынос:

Mono.fromCallable(() -> repo.findLegacy(id))
    .subscribeOn(Schedulers.boundedElastic());

Добавьте практику: WebClient вместо синхронного клиента, onErrorResume и timeout в цепочке, контекст подписки вместо переменных потока. И честный вывод: для обычного CRUD блокирующая модель проще в отладке и часто не медленнее.

Где спотыкаются

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

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

Третье: забывают, что диагностический контекст и данные авторизации не лежат в переменных потока при реактивной обработке. Идентификатор трассировки пропадает из логов, а попытка достать пользователя привычным способом возвращает пустоту.