[sjdmdlakziggy]

I can try, but the difficulty there is that Kafka is not really a traditional message queue system and the use cases are different. In short though, redundancy isn't sufficient to solve the reliability issues inherent in financial applications and transaction processing.

If you want througput, Kafka is the better option. Use a message queue for transaction processing against a specific target, where it is a requirement for you to have guaranteed, one-time and one-time only delivery, and possibly that its secret and should only be delivered to one target. You should conceptualize Kafka as being a tool to maintain a sort of distributed, global state. A message queue is more like getting served to go to court.

Technically, Kafka is an event stream, not a message queue (this can be confusing because event streams are often implemented at a surface level like message queues). The difference between an event and a message on a conceptual level is important though. There's plenty of good literature out there if you want to dig deep into the difference.

[pas]

thanks for the reply!

I'm aware that Kafka is low-level (and that there is kmq, which tries to implement a message queue on top of it https://github.com/softwaremill/kmq/ ), but the exactly-once semantics seems isomorphic to having the sender and the receiver doing a 2 phase commit using the log.

what are MQ's guarantees? how are they implemented?