CODEWITHSUNDEEP
asynchronousmicroservicesamqpservicebus
Mahesh Jasti
Mahesh Jasti

Reputation: 572

MicroServices - Async Communication via AMQP with multiple receivers scenario

Using Micro Services approach, I have Service A with 3 instances (A1, A2, A3) that can communicate with Service B which has (B1, B2, B3) instances via AMQP Message based Async communication. Example, by Azure Service Bus queues.

Part of Service A's action implementation, I have 5 Steps to be taken care and 2nd step of the 5 is to reach out to Service B to get some info and proceed further.

When I have a multi receiver approach, how does A2 instance of Service A can handle response from Service B, while actual request was made by A1 instance.

I would like to know how these kind of scenarios handled in multi sender + multi receiver approach in micro services.

Upvotes: 0

Views: 71

Answers (2)

Ubercool
Ubercool

Reputation: 1021

In multi node architecture where a distributed queue is being used the general approach is to have locking mechanism. Consider you have an object/request to process which is initially put into the queue. Any of the instances can pick that for processing. Your logic should be like:

  1. Attempt to acquire lock on the object. If successful process it. This will ensure tt a time only one instance will pick.
  2. Process the request and move it to another consistent state, so that when another instance picks it, it should have all the information
  3. Release the lock.

In this case there will be no issue if any instance picks the response in the second step you mentioned.

Another approach, along with locking goes like this:

  1. Try to lock the request. If successful.
  2. If successful, remove it from the queue
  3. Do the processing and move to another consistent state.
  4. Put the object back to queue and release the lock.

Of course as pointed by @Constantin there should be a link to map the response from B to the original object. Consistent state is another thing you should care about when an object can be handled by multiple instances. There shouldn't be any information which resides in a particular instance's memory.

Upvotes: 1

Constantin Galbenu
Constantin Galbenu

Reputation: 17683

In order to be posibile that the response from any of the service B instances to be handled by any of the service A instances then the response from B must contain all the information necessary to identify the request from A and resume the process, i.e. an Entity ID, Processs ID or something that most probable is opaque to B.

Also, this means that A1 (or whatever instance sends the request message to B) should not block or wait for the response from B.

Upvotes: 1

Related Questions