←back to thread

66 points enether | 2 comments | | HN request time: 0.001s | source

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.

Show context
crmd ◴[] No.44019403[source]
The US Federal Reserve uses IBM MQ for the FedNow interbank settlement service that went live last year.

Architecture info: https://explore.fednow.org/resources/technical-overview-guid...

replies(1): >>44019452 #
1. kev009 ◴[] No.44019452[source]
Likely implies z/OS is common on both sides. Given the stakes and availability needs not a bad choice.
replies(1): >>44025246 #
2. crmd ◴[] No.44025246[source]
In the linked doc they say it’s MQ on AIX but I believe it’s interchangeable with Z.