News for hackers. Stuff that matters.

A comment on SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue. Parent comment

Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by RhodesianHunter on Tuesday April 11, 2023 @07:30PM (#35533146)
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.
[ Parent | on HN ]
Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by Footkerchief on Tuesday April 11, 2023 @07:38PM (#35533210)
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.
[ Parent | on HN ]
Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by Closi on Wednesday April 12, 2023 @02:23AM (#35535707)
I don’t think it should be an ID - these platforms are really made for creating distributed event-driven systems.
[ Parent | on HN ]
Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by jwmoz on Wednesday April 12, 2023 @06:29AM (#35537488)
The idea is your task should just run off an ID, no point passing all that data around.
[ Parent | on HN ]
Re:SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a... by Closi on Wednesday April 12, 2023 @11:59AM (#35541869)
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.

[ Parent | on HN ]