zlacker

>>Kinran+(OP)
TIBCO Rednezvous, https://www.tibco.com/products/tibco-rendezvous, is the first thing that came to my mind from previous experience in the financial industry working with real-time market data. Although I'm not sure if it has built-in KV support for dealing with large payloads like NATS does, TIBCO RV and their related software packages are worth checking out to see what an long time established commercial product offers. Which leads me to...

... the protocol is text-based like HTTP with CR LF for field both for the client, https://docs.nats.io/reference/reference-protocols/nats-prot..., and cluster protocols, https://docs.nats.io/reference/reference-protocols/nats-serv... -- which means encoding overhead if your payloads are binary. So depending on your definition of performance, ymmv.

I really do not see how implementing an API across multiple languages is easier by making a new linefeed-based protocol, https://github.com/nats-io/nats-server/blob/0421c65c888bf381..., than just using code-generated JSON or gRPC (Protobuf or Flatbuffers). One could then write subscriptions/clustering algorithms in a protocol-neutral library.

>>no_cir+xS5
I'm not sure how much it will reduce your skepticism, but I believe NATS was actually created by the same person who created TIBCO RV: https://twitter.com/derekcollison/status/1163299967089254402

Derek seems like the kind of person who might know a thing or two about messaging systems.

I really like what NATS has become, and I do appreciate the simplicity of the protocol.