4

I have multiple clients A (main application) and multiple clients B (payments service).

If I publish a message from client A that will be processed and answered on client B (publishing an answer in another topic), how to capture this answer on client A?

The problem is that client A has multiple instances, so I can't guarantee that the exactly same instance that triggered the request will receive the response (PubSub will randomly pick one instance).

Saw that other brokers like RabbitMQ have "reply-to" option. Is there anything similar on Google PubSub?

That way, I could simulate a "synchronous" operation on client A and only answer to the user when processing/response is finished, instead of dealing with this check on front-end every time.

Thank you!

Pedro Barros
  • 1,326
  • 1
  • 12
  • 19

1 Answers1

4

Decoupling publishers from subscribers is one of the core features of Cloud Pub/Sub, which follows the publish-subscribe pattern. There’s currently no support in Cloud Pub/Sub for sending responses from subscribers directly to an entity that published a given message.

You could work around this by including information about the instance of client A that published a given message, so client B could figure out which instance of client A to notify once processing has finished. For example, client B could send an RPC directly to the publisher, or if there are few enough instances of client A, they can each have dedicated topics where they receive “processing complete” messages as subscribers (on a topic that client B is the publisher for).

Potential issues to watch out for while you think about the right approach:

  • Cloud Pub/Sub offers at-least-once delivery. There is a possibility of having duplicate messages sent to subscribers, and your system will need to be resilient to this.
  • What happens if a given instance of client A or client B crashes at any point in your process? Would it introduce the risk of processing erroneous/duplicate payments?
Desmond Foo
  • 181
  • 4