Что ответить пользователю: сразу ответить или оставить ждать
Что проверяют
Умеете ли вы выбирать между синхронным и отложенным ответом и понимаете ли, чем сервис платит за каждый вариант. Вопрос про проектирование ручки, а не про вежливость: ждут разговора о бюджете времени, таймаутах и судьбе начатой работы.
Как отвечать
Отталкивайтесь от бюджета ответа. Укладывается операция в него и зависит только от своих ресурсов, отвечайте сразу. Долгая или зависящая от внешней системы, принимайте задачу: возвращайте её идентификатор с кодом 202 Accepted и адресом статуса, а результат отдавайте опросом, уведомлением на вебхук или через постоянное соединение.
Что сказать про реализацию на Go:
contextс дедлайном пробрасывается от обработчика вниз, во все запросы к базе и по сети, и работа прекращается поctx.Done(), а не продолжается в никуда;- долгая задача уходит в очередь и исполняется воркером, а не горутиной, привязанной к жизни запроса;
- приём задачи делается идемпотентным по ключу от клиента, иначе повтор после разрыва создаст вторую;
- статус задачи это отдельный ресурс с понятными состояниями, включая отказ и его причину;
- полезен промежуточный вариант: отдать быстрый приблизительный результат из кэша и пометить его как неполный.
Отдельно проговорите деградацию: что вернуть, когда смежный сервис молчит, и почему честная ошибка с правом на повтор лучше висящего соединения.
Где спотыкаются
Держат соединение и надеются на клиентский таймаут. Клиент уходит, а горутина, запросы к базе и внешние вызовы продолжаются: под нагрузкой получается лавина бесполезной работы. Контекст запроса существует ровно для этого.
Второе: запускают go doWork() прямо из обработчика. Такая задача теряется при перезапуске процесса, не имеет повторов и наблюдаемости, а паника внутри горутины кладёт весь сервис, потому что перехватить её некому.
Третье: отвечают кодом успеха на задачу, которая ещё не выполнена. Клиент не отличает готовый результат от обещания, пишет в лог успех и идёт дальше, а расхождение всплывает через час у пользователя.