Веб-приложение кладёт задачу в брокер, отдельный Celery worker её исполняет. Падение веб-процесса не равно падению worker; повторную доставку нужно считать нормальным событием.
Как устроена интеграция Python-приложения с Celery и Redis/RabbitMQ? Что происходит, если во время выполнения тяжелой фоновой задачи бэкенд падает, и как обеспечить идемпотентность — повторяемость без ошибок — этой задачи?
Веб-приложение кладёт задачу в брокер, отдельный Celery worker её исполняет. Падение веб-процесса не равно падению worker; повторную доставку нужно считать нормальным событием.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Веб-приложение кладёт задачу в брокер, отдельный Celery worker её исполняет. Падение веб-процесса не равно падению worker; повторную доставку нужно считать нормальным событием.
Передавайте идентификатор операции, а не несохранённое состояние объекта. Постановку связывают с commit бизнес-транзакции, при требовании надёжной доставки используют transactional outbox. Идемпотентность обеспечивают уникальным ключом операции и атомарным сохранением результата, для внешнего API — его idempotency key. Отдельно проверяют настройки подтверждений, повторов и восстановления задач конкретного брокера: никакая одна опция не даёт exactly-once для произвольных побочных эффектов. При перезапуске worker задача должна безопасно продолжиться или повториться без повторного списания и дублирования данных.