Как оповестить клиента о готовности результата проверки паспорта

Что проверяют

Умеете ли вы спроектировать асинхронный процесс: проверка идёт долго, и держать HTTP-запрос открытым нельзя. Важно, зададите ли вы уточняющий вопрос, кто клиент: внешняя система по API или человек в приложении. Следом спрашивают, как не потерять уведомление и не отправить его дважды.

Как отвечать

Каркас: запрос на проверку ставит задачу в очередь и сразу отвечает 202 Accepted с идентификатором. Проверку делает воркер (Celery, RQ, Dramatiq, arq), а клиент узнаёт о результате одним из способов:

• опрос: GET /checks/{id} возвращает pending, done или failed. Самое простое и надёжное, частотой управляет клиент, сервер может подсказать её заголовком Retry-After;
• вебхук: для B2B-клиента. Он регистрирует URL, вы шлёте POST, когда готово. Обязательны подпись HMAC в заголовке, ретраи с экспоненциальной задержкой, event_id для идемпотентности у получателя и опрос как запасной путь;
• SSE или WebSocket: если результата прямо сейчас ждёт веб-страница. В FastAPI это StreamingResponse или WebSocket, а события от воркера к веб-процессу идут через Redis pub/sub;
• push, почта, SMS: если ждёт человек, который может закрыть приложение.

Надёжность: воркер пишет результат и запись «надо уведомить» в одной транзакции (transactional outbox), отдельный процесс рассылает и помечает отправленное. Иначе падение между записью результата и отправкой теряет уведомление.

Паспортные данные это персональные данные. В уведомлении только факт готовности и идентификатор, сам результат клиент забирает авторизованным запросом.

Где спотыкаются

Держат синхронный запрос, пока идёт проверка. Под нагрузкой все воркеры веб-сервера заняты ожиданием, и сервис встаёт.

Отправляют вебхук один раз, без подписи и ретраев. Первый же сбой на стороне клиента означает, что о результате он не узнает никогда.

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