CODEWITHSUNDEEP
design-patternsasynchronousarchitecturemicroservices
whoami
whoami

Reputation: 1627

Acknowledgement to clients on asynchronous microservice

I read everywhere that service to service calls should be asynchronous in microservices. When the request has to pass through 2 or more async services, how can we do the client acknowledgement?

Here is my real time scenario. We are developing an email sending functionality in our organisation. We are planning to have 4 API services for this in the following order.

  1. Public API - exposing the email functionality to public
  2. Validation API - to validate the genuineness of the email and other fields
  3. Template fetching API - fetch the email templates from database/CMS and prepare the final content to be sent
  4. Email sending API - will receive the recipient and the email content

The problem is, we have to acknowledge the client who initiated the request with some id if successful, otherwise have to return the error code. If we have to adapt the best practice of making asynchronous service to service call, how we can acknowledge the client from Email sending API(final API)?

Upvotes: 1

Views: 1373

Answers (1)

dbugger
dbugger

Reputation: 16464

The simple approach is to create a token that the client can use to check the status of the request at a later time. You will need to add a GetStatus method to the public API to return the status when requested.

Create a GUID when the initial request is received, return this token to the calling client. This will be their acknowledgement that the request was received. Persist the token and record it with the request's current status, which will initially be Received. Call the Validation API with the request and include the token.

When the Validation API has completed its work, it will update the status of the request. If there is a validation issue, it will update the status with an appropriate error message, otherwise it will update the status to Validated and then call the Template API, passing along the request and the token.

Repeat the above with the Template API and Sending API. When the Sending API has completed its work -- it should simply update the request's status to Complete.

The client can call the GetStatus method on the API at any time simply by supplying the token returned by their initial request. The method should simply return the request's status or a Not Found status if a non-existent GUID has been supplied.

The advantages of this is that you don't have to get into callbacks and other craziness and the calling client only needs to worry about 2 things: making a request and checking its status. The client can be as concerned or unconcerned about the status as it wants to be. It also lets you add further services in the chain without having to rewrite the external interface.

The nuances involve how and how long to persist the request statuses. Which really depend on system demand and available resources. Could be a database, a cache or some combination.

Upvotes: 2

Related Questions