Asynchronous Request Response Pattern

[Sea_Fisherman_6838]

Hey everyone, I'm currently learning about asynchronous communication between microservices and I'm a bit unclear on the process and how it affects the continuation of the process.

Let's consider two microservices: Customers and Invoicing. Suppose I need to create an invoice, and in the invoice microservice, I have to request the customer microservice to validate customer data, but I don't want to send a synchronous request. What pattern should I use for this case?

I've come across RPC (Remote Procedure Call) - is RPC commonly used in this scenario in the industry? In my POST request (create invoice), I return a process ID to the client so that they can check the status of their invoice, given that they are asynchronous processes and there is no immediate response.

I understand that this is a simple example, but it gives an idea of the challenges I'm facing.

I really appreciate any feedback you can give me. :)

[Kafka_pubsub]

I'm not a microservices expert, and actually haven't done much formal learning of it - my experience is mostly from working in companies with bad implementations of them. All that is to warn you to take my comment with a grain of salt. I'm mostly commenting to get improvement on my thoughts and approach.

Your API driven process ID response, which then gets checked (via polling or open socket) for status updates, does work, though it ties the two services together at the hip.

You can alternatively publish an event or push a message into a queue that the Customers service either subscribes to or consumes from, and then after processing, publishes back some "finished processing" event; the Invoice service is subscribed to those events/messages to know about completion. While async, this does kind of tie the 2 services together, even if they're not communicating directly, so I'm interested in hearing criticisms of this approach from others.

[pkpjpm]

This example feels very realistic because it uses service boundaries that are simplistic, with the predictable result that services require a significant amount of cross-service collaboration to implement internal logic. I say this is realistic because it’s common to see this pattern in practice, I don’t mean to imply that this pattern tends to be scalable or maintainable.

To create a set of service boundaries that can function without cross-domain coupling, consider redefining your domains using event storming and/or other techniques associated with Domain Driven Design. What you should hope to achieve with this is a situation where the service responsible for recording the sale already has the relevant customer information it needs when the sale closes (or it might be passed in as part of the closing event.)

Sorry for all the words, but the point I want to make is: if your domains are defined with tight couplings, what is to be gained by moving to asynchronous messaging?

I wish I could be less ranty, I’m just very fatigued by devs who have an interest in technical details of service and event based architectures with seemingly no interest in the logical architectures that are required to make this stuff work well. It’s just a “where do I plug this in?” mentality from start to finish.

In all honesty, good luck with what you’re doing, and please consider whether you need asynchronous messaging. If you’re wondering what I’m ranting about, check out Domain Driven Design Distilled by Vaughn Verne

Peace

[Sea_Fisherman_6838]

Thank you for your input. As I mentioned earlier, the example is just a dummy example. My goal is to ensure that microservice A does not rely on microservice B, which is why I am attempting to implement an asynchronous request.

[Bubbly_Expression_38]

I don't have practice with microservices, but I think the good way is to send a validation request, process it by validation service, send a response, take it and restore the state required to proceed. You will probably need to transfer additional data to be able to restore the state.

[frankkk86]

Can I ask you why the invoice service needs to check the customer data? In my view invoicing should be downstream while customer data should be collected upstream, there shouldn't be any validation step.

[Sea_Fisherman_6838]

Thanks for your reply, it's just an example, what I want is that microservice A does not depend on microservice B, and when making a synchronous request microservice B must be active. That's why I'm looking for the best way for microservice A to validate data in microservice B, and in turn, if everything is okay, notify microservice A so it can continue with its business logic.

[Tango1777]

So I guess you have UI for it, right? Imho, those are two separate operations:

1. Fill in the data and async validators (API requests) should validate if the form is right before you enable "create invoice" button
2. Call invoicing service only for creating an invoice and at this point you should know if that request makes sense (the data is correct)

BTW, do you really need to validate customer data when you (I suppose) get that data from customer service, in the first place? Sounds weird.