> Как клиент узнает результат обработки файла (Go)

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

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

Пример по STAR

Ситуация: в сервисе загрузки и обработки документов клиенты ждали ответа синхронно, и при больших файлах запросы отваливались по таймауту. Задача: сделать так, чтобы клиент надёжно узнавал результат обработки, не держа соединение открытым. Действие: я предложил асинхронную схему. Клиент загружает файл и получает task_id. Дальше worker pool на Go обрабатывает файл, а статус пишется в Redis и БД. Клиент может либо опрашивать endpoint статуса, либо получить callback на свой webhook. Для устойчивости добавили идемпотентность по task_id, ретраи и dead letter queue. Результат: время ответа API снизилось, количество таймаутов упало, а клиенты получили предсказуемый контракт. Мы также добавили метрики по времени обработки и алерты на застрявшие задачи.

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

Сначала назовите модель взаимодействия: синхронная или асинхронная. Затем объясните, как клиент получает результат: polling, callback, webhook, event, websocket. После этого покажите, как вы гарантируете надёжность: идемпотентность, ретраи, статусы, таймауты, dead letter queue. Обязательно упомяните, где хранится состояние и как клиент отличает временную ошибку от финальной. В конце добавьте, какие метрики и логи помогают диагностировать проблемы.

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

Интервьюер проверяет, умеете ли вы проектировать асинхронные сценарии и думать о клиенте. Ему важно увидеть понимание trade-off между polling и callback, а также знание идемпотентности и ретраев. Он смотрит, как вы описываете контракт статусов и поведение при сбоях. Для senior-уровня критично показать опыт эксплуатации: метрики, алерты, обработка застрявших задач и эволюция API без поломки клиентов.

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

Часто кандидаты предлагают только синхронный ответ и не учитывают таймауты. Другая ошибка - отсутствие идемпотентности, из-за чего повторная загрузка создаёт дубли. Некоторые забывают про финальные и промежуточные статусы, и клиент не понимает, завершилась ли обработка. Также опасно полагаться только на callback без fallback polling. И наконец, многие не упоминают мониторинг и dead letter queue, хотя без них асинхронная схема быстро становится неподдерживаемой.