Reputation: 23207
I've been reading for some tome ago about "asynchronous communication between microservices" and its benefits.
Something doesn't fit on my mind:
I mean, I can design a "barista system" like this:
Dispatchning an event from "counter service" and send a "coffee is ready" to client, when "counter service" receive an "coffee is ready event" from "barista service".
Some counterparts here:
I mean, what about if client is only able to handle synchronous communication on a "asynchronously inter-service communication"?
Which feedback techniques are available here? I mean, are there more modern techniques besides of "polling request status"?
Upvotes: 1
Views: 178
Reputation: 20551
If a client is only able to communicate synchronously (i.e. no interaction besides client makes request and then client gets response is possible), then you essentially have two options:
You can respond to the initial request with some unique identifier that the client can use to request a [more] final response. In the coffee bar example, this would be like placing an order over the phone, being told an order number, coming into the shop at some later point, and asking "is order XYZ ready?". This is fairly lightweight, at least as long as the client doesn't just spam you with request updates (as in rapid polling).
Alternatively, you can present a synchronous API even if the internals are asynchronous: you just need a component that holds the interaction open until the response is final. The analogy here would be if an order is placed over the phone, the order taker is required to stay on the line with the customer until the customer comes in to pick up the coffee. If the connection breaks, the coffee is lost.
Upvotes: 1