Ребятки, подскажите, как правильней выстроить архитектуру. Есть база данных MariaDB,

в которой хранится около 7 млн. сущностей. Эти сущности нужно обрабаывать, хочу сейчас обработку вынести в очереди (NATS). После обработки, у сущности нужно обновлять дату обработки. Сейчас вижу этапы конвейера такие:
1) воркер выбирает с базы и пушит в очередь (fan-out)
2) с другой стороны очереди консьюмеры делают работу
3) ... вот тут проблемка, как уведомить продюсера о статусе работы, знаю что в NATS есть механизм отчета, использовать его, или создать вторую очередь куда пушить статусы?

Сама проблема вот такая:
1) мы делаем выборку из базы самых старых не обработаных сущностей. Пушим их.
2) допустим, в очереди возникла очередь (сорян за тафтологию)
3) сервер запрашивает эти сущности снова, т.к. есть лаг: сущности вроде и не обработаны, но они уже добавлены в очередь.

Я с очередями не работал, но был бы рад если бы кто-то мне сказал что в них можно добавить уникальный констрейнт чтобы нельзя было запушить одну и ту же сущность с одним идентификатором дважды?

Да и вообще, приветствуются любые советы или рекомендации как лучше сделать.

Что значит "уведомить о статусе"? Имеется в виду окончание обработки или какие-то промежуточные статусы? И что происходит с сущностью в базе после окончания обработки? > уникальный констрейнт чтобы нельзя было запушить одну и ту же сущность Нет, так нельзя. Брокер, как правило, вообще не знает, что там внутри сообщений находится, какие "идентификаторы". > сервер запрашивает эти сущности снова, т.к. есть лаг: сущности вроде и не обработаны, но они уже добавлены в очередь. Нужно сразу после забора пачки и отправки ее в очередь ставить в базе флаг, что сущность отправлена на обработку. Возможно, даже не флаг, а лучше отдельное таймстамп поле, на случай, если сообщения где-то потеряются в очереди, можно будет повторно селектить по этому таймстампу в порядке возрастания с какими-то интервалами и отправлять на переобработку. После окончания обработки - соответственно ставится другой флаг (или таймстамп), что сущность полностью обработана. Если продьюсер многопоточный или подразумевается много продьюсер-воркеров, нужно делать апдейт в одной транзакции с выборкой с row lock-ом, для избежания повторной отправки. В postgresql для этого есть select for update, в марии хз. Можно и без лока, но это увеличивает вероятность повторной переотправки (но повышает скорость обработки). > как уведомить продюсера о статусе работы Либо вторая очередь с отчетами, которую читает продьюсер, либо консюмеры дергают вебхук-апишку, выставляемую консьюмером, по которой он обновляет базу. Вы, кстати, уверены, что NATS подходит? Если именно чистый NATS, а не Streaming, то он эфемерный полностью насколько помню, любое падение/перебой в сервисе и сообщения в очереди потеряны - в случае продьюсера это не так проблематично если регулярную переотправку делать, а в случае статусов могут потеряться обновления что сущность обработана, это может быть критично если полная обработка должна выполняться только 1 раз