CODEWITHSUNDEEP
asynchronousarchitecturemicroservices
Iblisto
Iblisto

Reputation: 339

Getting response for user-initiated action from microservices with asynchronous communication

I'm not sure how to put this into words well, so here's a (rather common) example.

Say a user is using our blog service and clicks the "Save" button to publish his awesome blog post. Now a common user story would be, he will be notified of his action's result - a notification like "Successfully published!" or "An error occurred. Please try again.".

In a synchronous world, this is not hard - you send a request to the server, wait for a response, and based on the response show a notification.

But let's imagine our server is in microservice oriented architecture, leveraging asynchronous communication; we use a message queue for example. An API gateway microservice takes a request from front-end, publishes its message into the queue. Then a "consumer" microservice sends the result of the consumed message to the front-end. What's a good way to give back the result of user action in this case? If we set up a websocket session to take such responses for example, the code to initiate user action and the code to give feedback for user action would end up being completely separate, although it happens in the same user workflow. Is this a sensible idea? Or I'm missing some fundamental ideas here?

Upvotes: 0

Views: 727

Answers (1)

monad
monad

Reputation: 125

The process you describe is a good one and brings some 'hidden' benefits you may have not realized yet. I think the main point here is WHAT to communicate to the user.

I think in this scenario you should response immediately saying, the blog post was dispatched to publish. You don't say, it was published, but that the process of publishing it was initiated succesfully. By this you say to the user: your nice blog post is safe (messaging technology will assure this) and we are taking care of making it public. Relax and wait for it being published in a second or two, or a minute. The hidden benefit of this approach is, that you may apply additional processing before making the post public, e.g. checking by a moderator?

Everything else is just like you described. It's really just the way how you communicate it to the user. Clear communication of what your system is doing here is the key.

Upvotes: 1

Related Questions