Использовали ли инструменты для асинхронности в Django, например Celery и Redis

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

Понимаете ли вы, зачем выносить работу из цикла запроса, и знаете ли правила написания задач.

Как отвечать

Основная связка: Celery это система очередей задач, брокер (Redis или RabbitMQ) хранит сообщения, воркеры выполняют задачи в отдельных процессах. Django-представление кладёт задачу в очередь и сразу отвечает пользователю.

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

Роли Redis в проекте на Django обычно три сразу: брокер для Celery, хранилище результатов задач и кэш самого Django. Плюс распределённые блокировки, чтобы одна и та же периодическая задача не запустилась дважды.

Что важно знать про написание задач:

• идемпотентность: доставка может повториться, поэтому повторное выполнение не должно создавать вторую сущность или отправлять второе письмо;
• передавать идентификатор, а не объект модели. Объект сериализуется, устаревает и к моменту выполнения может уже не соответствовать базе. Правильно передать первичный ключ и загрузить свежую запись внутри;
• ограничение времени (time_limit, soft_time_limit) и повторы с задержкой, иначе зависшая задача займёт воркер навсегда;
• отдельные очереди для быстрых и медленных задач, иначе долгий отчёт заблокирует отправку писем;
• периодические задачи через Celery Beat, и там же нужна защита от одновременного запуска на нескольких узлах.

Мониторинг обычно через Flower или метрики очереди: длина очереди и время ожидания показывают, справляются ли воркеры.

Альтернативы стоит назвать: dramatiq, django-q, RQ проще Celery, а асинхронные представления Django решают другую задачу и фоновой очереди не заменяют.

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

Передают в задачу объект модели.

Не делают задачи идемпотентными.

Держат все задачи в одной очереди.

Считают асинхронные представления заменой Celery.