AWS Serverless and Microservices — Part 3

Continuing with our Design Journey of YAFDP Application using AWS Serverless Stack from earlier parts —

Part 1 — How to structure Microservices using AWS Serverless stack and using Synchronous Request-Response pattern with API Gateway and Lambda

Part 2 — Covers Designing of Asynchronous event submission using API Gateway, SQS and Lambda. And how to implement Saga Orchestration Pattern with Serverless Step Function service.

Part 3 (This blog) — Covers approach of sending the status of asynchronous task submission, in our case New Food Order Placement, to the client.

Part 4 — Covers Placing New Food Delivery Order using Choreograph Saga Event Driven Pattern.

Part 5 — Using Serverless stack for designing Notification Service.

Ok, before we see the Choreograph way of Saga, let’s make our User aware of the order status on his Web Browser/Mobile Application from where he initiated the Food Order. He very much has the rights to know about each and every status change of his Order 😜.

Well there are quite a few ways for the client to know the status change. Let’s see couple of them—

1. Polling Pattern — Client makes a call every X second to get the status. In our example, on submission of the New Order, Server responds back with a unique ID (UUID in our case). Client can use this ID to get the status. Easy but not efficient.
2. WebSocket’s Pattern — After getting a unique ID of the order, client can initiate a WebSocket connection. Once the connection is established, Server can start pushing the status of the order as and when it gets changed on the server side. Yes, data starts flowing from Server to Client without client requesting for it. On receiving the Notification, client can take further action. For instance, it can invoke additional Status API call to get detailed status of the order. This approach has got some effort involved but is much more efficient than the earlier approach and also provides good User Experience as it provides real time updates to the end user.

Let’s see how we can implement WebSocket’s pattern using AWS Serverless Ecosystem —

WebSocket Pattern to communicate Order Status change

In the above flow,

1. On submission of a new Order, unique UUID is returned back to the client.
2. Client initiates a WebSocket persistent connection with Notification API Gateway endpoint.
3. WebSocket API Gateway sends an OnConnect event to the OnConnect Lambda function passing the connection details.
4. WebSocket API invokes the Lambda Authorizer before step #3. If the Authorizer allows the request, step #3 gets executed, else the request is Denied.
5. OnConnect Lambda function saves the unique Connection ID and User ID in the DynamoDB.
6. Whenever Notification Service wants to communicate anything to the end user, it searches the Connection ID attached with the User ID from the Connection DynamoDB table.
7. Once it gets hold of the Connection ID, it makes Post API call on the WebSocket Gateway passing the payload as input.
8. WebSocket Gateway then delivers the Notification to the caller.
9. On receiving the Notification, depending on the payload content, client can make additional Status API call to get more details.

To get more details on the AWS API Gateway WebSocket, please take a look at the below link —

Announcing WebSocket APIs in Amazon API Gateway | Amazon Web Services

This blog was a short one. In the next version, I plan to cover below things —

1. Design of Notification Service &
2. Saga Choreograph Pattern for Order Placement (I know, this is pending from part #2)

Till then, Cheers!!!