Вопрос проверяет, умеете ли вы проектировать асинхронные сценарии, где результат недоступен сразу, но требуется управляемый жизненный цикл операции.
Долгоживущую операцию обычно запускают асинхронно и сразу возвращают клиенту идентификатор задачи. Основная работа выполняется в фоне — через очередь, воркер или отдельный сервис. Клиент позже получает результат через polling, callback или событие. Важно хранить статус задачи и уметь обрабатывать сбои и повторы. Такой подход снижает нагрузку на API и повышает устойчивость системы.
Долгоживущая операция — это операция, выполнение которой может занимать секунды, минуты или часы и не подходит для обработки в рамках одного HTTP-запроса.
Инициация операции
API принимает запрос.
Валидирует входные данные.
Создаёт запись о задаче со статусом pending.
Асинхронный запуск
Задача отправляется в очередь или фоновый исполнитель.
API сразу возвращает task_id.
Фоновая обработка
Воркер выполняет работу.
Периодически обновляет статус (running, failed, completed).
Получение результата
Клиент запрашивает статус по task_id (polling).
Или получает уведомление (webhook, event).
# POST /tasks
# -> { "task_id": "abc123" }
# GET /tasks/abc123
# -> { "status": "completed", "result": {...} }
Идемпотентность запуска (повторный запрос не создаёт дубликат).
Timeout и retry на уровне воркеров.
Хранение промежуточного состояния, если операция состоит из шагов.
Очистка результатов, если они больше не нужны.
Асинхронная модель с task_id позволяет безопасно и масштабируемо выполнять долгие операции без блокировки API и клиентов.
