[giovannibonetti]

It's all a matter of how much throughput you need. A queuing system can handle, in the same hardware, orders of magnitude more than a traditional SQL database that writes rows to disk in a page-oriented fashion.

If your load is, say, a few hundred writes/second, stick with the database only, and it will be much simpler.

[arcticfox]

how does that help if you still have to have a DB tracking status? you still need the same order-of-magnitude of DB throughput

[RhodesianHunter]

No, because you only need to read and write ids and maybe timestamps to your db, both of which are trivially indexed, rather than the whole blob of your message payload.

[Footkerchief]

In many cases, the message payload is (or should be) an ID anyway. It's seldom desirable for the message payload to include a copy of an external source of truth, because it can cause sync issues. There are exceptions, of course.

[Closi]

I don’t think it should be an ID - these platforms are really made for creating distributed event-driven systems.

[jwmoz]

The idea is your task should just run off an ID, no point passing all that data around.

[Closi]

How do you get the data relevant to that ID?

If the answer is a call to a shared database, you might as well not have RabbitMQ.