В каких случаях не следует использовать Celery

Celery не подходит для задач, требующих немедленного (синхронного) ответа пользователю, так как его основное преимущество — асинхронное выполнение. Ключевые анти-паттерны:

1. Синхронные и быстрые операции. Почему? Накладные расходы на сериализацию задачи, отправку в брокер (RabbitMQ, Redis) и её получение воркером могут превышать время выполнения самой операции. Это делает систему медленнее, а не быстрее.

2. Задачи, критичные к задержкам (real-time). Почему? Celery не гарантирует мгновенное выполнение. Задача может ожидать в очереди, пока воркер не освободится. Для real-time систем (например, обработка HTTP-запроса) это недопустимо.

3. Задачи, требующие сложного состояния приложения. Почему? Передача большого или сложного контекста (например, объектов сессии) в воркер — плохая практика. Это усложняет код и может привести к состоянию гонки (race condition) или использованию устаревших данных.

Пример плохого использования:

# Плохо: быстрая операция, результат которой нужен немедленно.
# Вместо выноса в Celery, эту функцию нужно вызывать напрямую.

from myapp.models import User

@celery.task
def check_user_exists(username):
    return User.objects.filter(username=username).exists()

# В коде представления (view):
# user_exists = check_user_exists.delay('john').get() # Это анти-паттерн!