> Как реализована обратная связь с клиентом при долгой обработке файла (Go)

Короткий ответ

При долгой обработке файла я организую обратную связь через асинхронную модель: клиент получает идентификатор задачи, а статус отслеживает через polling, webhook или streaming. В Go для этого использую worker pool, каналы и контекст с отменой. Прогресс сохраняю в Redis или БД, чтобы клиент видел этапы и мог отменить операцию.

Пример по STAR

Ситуация: в сервисе импорта больших CSV-файлов клиенты ждали ответа по HTTP и получали таймаут. Обработка занимала до десяти минут, а промежуточный статус был недоступен.

Задача: сделать прозрачную обратную связь без блокировки HTTP-соединения и с возможностью отмены.

Действие: я разделил поток на три части. Первая - приём файла и создание job с UUID, клиент сразу получал 202 Accepted и ссылку на статус. Вторая - асинхронная обработка через worker pool на Go, где каждый этап обновлял прогресс в Redis. Третья - API для polling статуса и endpoint для отмены через context cancellation. Дополнительно добавил webhook для уведомления по завершении.

Результат: таймауты исчезли, клиенты видели прогресс в реальном времени, а отмена освобождала ресурсы. Нагрузка на HTTP-слой снизилась, так как долгие соединения больше не удерживались.

Как отвечать на собеседовании

Сначала опишите контракт взаимодействия: клиент получает job id и способ отслеживания. Затем объясните, почему выбрали polling, webhook или streaming, и какие trade-off учли. Покажите, как в Go реализована асинхронность: goroutines, каналы, context. Упомяните хранение прогресса и идемпотентность. В конце добавьте, как обрабатываете отмену и ошибки, чтобы клиент не остался без ответа.

Что проверяет интервьюер

Проверяется понимание асинхронных паттернов, работы с context в Go и проектирования API для долгих операций. Также важно, как вы балансируете между простотой polling и сложностью streaming. Интервьюер смотрит на зрелость решений: идемпотентность, отмена, ретраи, хранение состояния. Ожидается, что senior не просто назовёт инструменты, а объяснит trade-off и влияние на UX.

Типичные ошибки

Часто кандидаты предлагают держать HTTP-соединение открытым до конца обработки, что ведёт к таймаутам и блокировке ресурсов. Другая ошибка - отсутствие механизма отмены, из-за чего задачи продолжают выполняться после отказа клиента. Некоторые забывают про идемпотентность и хранение прогресса, поэтому при ретрае клиент теряет статус. Также опасно игнорировать backpressure: без ограничения worker pool очередь задач растёт бесконтрольно.