Re:Do you really need Redis? How to get away with just Postg...
by hughrr on Saturday June 12, 2021 @07:02AM
(#27483566)
The point of queues is sequencing, storage and decoupling of events for the sake of scalability and durability.
By putting it in the same transactional store with the same transactional boundaries you’re instantly shooting the whole point.
Not only that, most queues define boundaries between different logical systems where transactional boundaries do exist. At which point your database’s transaction scope is extremely limited in capability.
In the real world of messaging transactions span more than just the database engine.
It’s just bad architecture. Full stop.
Re:Do you really need Redis? How to get away with just Postg...
by dragonwriter on Saturday June 12, 2021 @10:14AM
(#27484649)
> The point of queues is sequencing, storage and decoupling of events for the sake of scalability and durability.
The point of queues in any particular application is some subset of that; the calculus of implementation approaches that make sense depends not on the abstract point of queues in general but on the concrete point of queues in your use case.
Re:Do you really need Redis? How to get away with just Postg...
by victor106 on Saturday June 12, 2021 @07:37AM
(#27483753)
Having a separate queue makes sense across application boundaries. If you need queuing mechanisms in your own application you should be able to get by with a dB for 99% of use cases
Having the queue on its own means you have to handle exceptions like "job is done but queue didn't get updated" or get into distributed transaction which is very different challenge.
Also, operationally having one inherently stateful component (db) versus two (db, queue) makes things a lot simpler to manage, deploy, update, etc.
Not claiming this is a perfect solution, just that the tradeoff isn't obvious.