Почему для хранения статусов задач может быть выбран Postgres, а не брокер сообщений?

Question

Брокер сообщений хорошо передаёт события, но плохо подходит для хранения актуального состояния. Postgres обеспечивает надёжное и долговечное хранение статусов. В БД легко сделать запрос текущего состояния и истории изменений. Также проще реализовать транзакционность и восстановление после сбоев. Поэтому Postgres часто используют как источник истины для статусов задач.

YeaHub · Accepted Answer

ОпределениеХранение статуса задачи — это поддержание актуального и консистентного состояния выполнения, доступного для чтения в любой момент.Почему брокер — не лучшее место для статусовБрокер ориентирован на поток событийСообщения читаются и “уходят”.Получить текущее состояние без дополнительной логики сложно.Сложность повторных чтенийНужно replay событий или отдельные consumer-группы.Это усложняет архитектуру.Ограниченные запросыНельзя просто сделать SELECT status WHERE task_id = ....Преимущества Postgres для статусовИсточник истиныЯвное хранение текущего состояния.Удобно для API и админ-интерфейсов.ТранзакционностьСтатус меняется атомарно вместе с бизнес-логикой.История и аудитМожно хранить временные метки, ошибки, попытки.Восстановление после сбоевПерезапуск сервисов не теряет состояние задач.Типовой сценарийБрокер используется для запуска и обработки задач.Postgres — для хранения их статуса и результата.ВыводPostgres выбирают тогда, когда статус задачи — это долгоживущее состояние, а не просто событие, и к нему нужен надёжный и удобный доступ.