⌛️ Webhook, SSE, WebSocket, polling или worker: что выбрать для долгой операции? ⌛️

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

При этом пользователь может:

▫️ сразу увидеть, что задача принята,
▫️ наблюдать за прогрессом,
▫️ закрыть страницу и вернуться позднее,
▫️ получить результат позже, даже если соединение прервалось,
▫️ иметь возможность повторить операцию или отменить её.

📌 Тут точно нужен асинхрон.


И далее появляется вопрос:
👉 Что использовать: webhook, polling, SSE, WebSocket или фоновую обработку?

Но эти варианты нельзя просто поставить в один ряд и выбрать один «правильный».

Эти механизмы не заменяют друг друга. Они решают разные части одной задачи.



1️⃣ Как отделить генерацию от запроса пользователя

Если операция занимает несколько минут, Backend не должен всё это время держать HTTP-соединение открытым.

Вместо этого он:
1. Создаёт запись операции со статусом QUEUED (в очереди).
2. Формирует job — задание с данными для запуска генерации.
3. Сохраняет операцию и job.
4. Возвращает 202 Accepted и operationId в ответ на API-запрос.

Дальше job забирает worker.

👉 Job — это описание того, что нужно выполнить.
👉 Worker — компонент, который забирает это задание и выполняет его.

В нашем примере worker не генерирует видео самостоятельно. Он вызывает внешний ИИ-сервис, получает providerJobId и сохраняет его рядом с внутренним operationId.

Очередь при этом не обязательна. В простой системе worker может читать задания из таблицы jobs (async_tasks). При росте нагрузки появляется брокер.

📹 Подкаст про асинхронную задачу и фоновую обработку



2️⃣ Как Backend узнаёт, что видео готово

Здесь выбираем между webhook и polling.

Webhook подходит, если внешний сервис умеет сам сообщать об изменении статуса. Это основной вариант, когда результат нужен быстро и мы не хотим постоянно опрашивать провайдера.

Polling нужен, если webhook не поддерживается. Backend периодически вызывает API для проверки статуса во внешней системе, пока не получит обновление.

❗️ Но даже при наличии webhook, polling может остаться как страховка: например, раз в несколько минут проверять незавершённые операции, по которым событие не пришло.

То есть часто выбор выглядит не как «webhook или polling», а как:

👉 webhook для основного потока + polling для reconciliation.

🎧 Подкаст про webhook и polling



3️⃣ Как показать прогресс пользователю

Это уже отдельное решение.

UI polling — если интерфейсу достаточно обновлять статус раз в несколько секунд.

SSE — между UI и Backend устанавливается постоянное соединение, Backend должен передавать в браузер односторонний поток обновлений по сущности: В ОЧЕРЕДИ → ОБРАБОТКА → ГОТОВО.
🎧 Подкаст про SSE API

WebSocket — если обе стороны часто отправляют сообщения в рамках одной сессии. Например, пользователь не только смотрит прогресс, но и управляет процессом, меняет параметры или отправляет команды на отмену во время генерации.
🎧 Подкаст про WebSocket API



📚 К посту я подготовила большой гайд с разбором всех механизмов и таблицей сравнения.


Сохраняйте и используйте, когда нужно спроектировать долгую операцию, интеграцию с внешним сервисом или отображение прогресса в интерфейсе 💙

#ИнтеграцииGA