0

I have 2 Microservices [A, B] and the service [B] has integration with legacy system [C]. The service [B] usually generates unique-identifier and includes it in the flow into [C], also passes it back to [A]. In that way reconciliation was handled between the systems.

The problem really started when there is a need for a service [D] that [A] has to invoke in parallel to inform [C].

While it makes some sense to have [A] generate the unique-identifier and send it to both [B] and [D] to solve the problem, its not that easy because of the cost of change in [C]. So we still somehow need to have the [B]’s unique identifier available for [D] to marry the data in [C].

Appreciate if someone can guide me if there is tactical pattern to solve this problem.

kalyanku18
  • 1
  • 1
  • Hi there, you tagged your question with `Domain Driven Design`. I'd suggest you elaborate on how `domain problem` looks like. What does those services do? What is the process? It makes sense to me for the process initiator to define the process identity. – Alex Buyny Oct 28 '19 at 23:34

1 Answers1

0

It’s a bit difficult following all the services without a diagram, but I’ll do my best. You say that C passes the identifier back to A in the current process, so I’m assuming this call structure

A -> B (create ID) -> C -> A

Now you want to introduce 

A -> D -> C -> A

And you need C to know which message from the ADC path is related to which message from the ABC path. Is that correct?

The best solution is to let A create the ID for everyone, like this

A (Create ID) -> B (use ID given by A) -> C -> A
A (Use same ID) -> D -> C -> A

If you can’t change the code to create a single ID in the A service, try 2 different message IDs. It would be clumsy since you would need storage somewhere so you can tell that msg123 comes from the same source as msgABC, but it would solve the problem.

This would give you

A -> B (create ID1) -> C -> A
A (Create ID2) -> D -> C -> A
Brad Irby
  • 2,397
  • 1
  • 16
  • 26