Replies in Queue Group

[Exagram]

NATS has two concepts:

• https://docs.nats.io/nats-concepts/core-nats/reqreply/reqreply_walkthrough
• https://docs.nats.io/nats-concepts/core-nats/queue

Can the two work together?

My scenario:

• Currently a lot of microservices are able to publish messages to file.process
• A pull-based consumer in a .NET BackgroundWorker while-loop thread listens to file.process and either publishes file.success or file.fail
• The same microservices will have pull-based consumer worker threads which would sequentially listen to filter subjects i.e.
  • microservice1 which services DomainA will pull messages from domainA.>,
  • microservice2 which services DomainB will pull messages from domainB.>
  • etc.
• However this approach won't listen to file.* events.
• Ideally I would want to listen to multiple filter subjects i.e.
  • domainA.>,file.* for microservice1
  • domainB.>,file.* for microservice2
  • etc.
• However I don't think multiple filter subjects and I'm forced to make each microservice listen to all messages:
  • > for microservice1
  • > for microservice2
• What a performance nightmare! I've got to find a better way...
• Rethinking I don't think I need multiple filter subjects. I only need my microservices to listen to specifically one instance of file.success or file.fail - the one that they caused with file.process.
• Ideally I would like the microservices to publish file.process with a reply-to field to their own inbox i.e.
  • microservice1 publishes file.process with a reply-to field to domainA.fileProcessed
  • The file processor reads the reply-to field and publishes the success/failure to domainA.fileProcessed
  • microservice1 pulls the message
  • microservice2 and friends don't snoop in

Questions:

• Does NATS support multiple filter subjects i.e. domain1.*,domain2.*,file.success,etc.?
• Can I mix NATS concepts of request-reply and pull-based consumer worker queue together as described above?

[scottf]

There is currently design work going on to handle multiple subjects in a subscription, not sure the timeline for that to be available and also not 100% sure if that will only apply to JetStream subjects, but for now you need one subscription per subject, i.e. domain1.> or file.success
You really can't mix the request-reply / JetStream concepts. If you publish a message to a subject that is part of the stream, the JetStream message will use the reply-to for it's ack handling. You could however user a message header to hold information to identify the sender's "address". I think either way you are not going to be able to get away with having only one subscription for everything if one of your subjects is core (not streamed).
If if both sets of messages are streamed, you might consider having message subjects like domainA.work.blah and domainA.file.blah which means you can subscribe to domainA.> and if you put domainA in the header the file processor will know what stream to publish it's response to.