Этот вопрос проверяет понимание компромиссов между скоростью, надёжностью и долговечностью хранения состояния.
Статус задач можно хранить в базе данных, in-memory хранилищах или в брокере сообщений. БД подходит для надёжного и долгоживущего состояния. Redis удобен для быстрых и временных статусов. Иногда используют гибридный подход: Redis для быстрого доступа, БД — для персистентности. Выбор зависит от требований к надёжности и времени жизни данных.
Статус асинхронной задачи — это сохранённая информация о текущем состоянии выполнения задачи и, возможно, её результате.
Реляционная база данных
Хранение статуса и метаданных в таблице.
Подходит для аудита и восстановления после рестартов.
Более медленная, но надёжная.
Redis / in-memory хранилища
Очень быстрый доступ.
Удобно для частых проверок статуса.
Требует аккуратной настройки персистентности или TTL.
Брокер сообщений
Статус кодируется в виде событий.
Хорошо ложится на event-driven архитектуру.
Сложнее получить “текущее состояние” без проекций.
Комбинированный подход
Redis — актуальный статус.
БД — финальный результат и история.
Часто используется в высоконагруженных системах.
# Redis: task:{id} -> running
# Postgres: tasks(id, status, result, updated_at)
Нужно ли хранить статус после перезапуска системы.
Требуется ли история изменений.
Частота чтения статуса клиентами.
Нет универсального варианта: выбор хранилища статусов — это баланс между скоростью, надёжностью и стоимостью поддержки.
