The space is confusing to say the least.Message queues are usually a core part of any distributed architecture, and the options are endless: Kafka, RabbitMQ, NATS, Redis Streams, SQS, ZeroMQ... and then there's the “just use Postgres” camp for simpler use cases.I’m trying to make sense of the tradeoffs between:- async fire-and-forget pub/sub vs. sync RPC-like point to point communication- simple FIFO vs. priority queues and delay queues- intelligent brokers (e.g. RabbitMQ, NATS with filters) vs. minimal brokers (e.g. Kafka’s client-driven model)There's also a fair amount of ideology/emotional attachment - some folks root for underdogs written in their favorite programming language, others reflexively dismiss anything that's not "enterprise-grade". And of course, vendors are always in the mix trying to steer the conversation toward their own solution.If you’ve built a production system in the last few years:1. What queue did you choose?2. What didn't work out?3. Where did you regret adding complexity?4. And if you stuck with a DB-based queue — did it scale?I’d love to hear war stories, regrets, and opinions.
First seen: 2025-05-18 05:50
Last seen: 2025-05-18 05:50