SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue

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 ]