Какие проблемы возникают при нескольких обращениях к базе и парсинге файла в обработчике запроса

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

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

Как отвечать

Начните с того, что поток обработки запроса ограничен: в Tomcat по умолчанию до 200 рабочих потоков, в HikariCP по умолчанию 10 соединений. Отсюда проблемы:

• N+1 и лишние обращения: запрос в цикле по строкам файла даёт сотни походов в базу, каждый с сетевой задержкой. Помогают пакетная выборка (WHERE id IN (...), JOIN FETCH, @EntityGraph) и пакетная запись (batchUpdate, hibernate.jdbc.batch_size);
• длинная транзакция: если парсинг идёт внутри @Transactional, соединение занято всё время разбора. Несколько тяжёлых запросов исчерпают пул, остальные будут ждать connectionTimeout (30 секунд по умолчанию) и падать. Разбор и валидацию делают до транзакции, в транзакции только запись;
• память: MultipartFile.getBytes() или DOM-парсер держат весь файл в куче. Для больших файлов нужен потоковый разбор: StAX для XML, Jackson Streaming API для JSON, построчное чтение CSV;
• таймауты: прокси обрывает соединение раньше, чем сервер закончит, работа продолжается впустую, а клиент присылает файл повторно;
• частичный успех: половина строк записана, на второй половине ошибка. Заранее решите, нужно всё или ничего, или запись валидных строк с отчётом.

Хороший ответ архитектурный: сервер принимает и сохраняет файл, отвечает 202 Accepted с идентификатором задачи, обрабатывает в фоне через очередь или Spring Batch, а клиент опрашивает статус. Виртуальные потоки Java 21 снимают дефицит потоков, но не дефицит соединений с базой.

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

Предлагают «сделать асинхронно» без деталей. Голый @Async не отвечает ни на вопрос о транзакциях и повторах, ни на то, как клиент узнает результат.

Кэшируют всё подряд вместо того, чтобы убрать запросы из цикла. Кэш прячет N+1, но не устраняет его.

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