AWS Serverless and Microservices — Part 2

Approach 1 — Place New Food Delivery Order
  1. Save order in the Database with status as Pending.
  2. Initiate Payment using Payment Service
  3. On confirmation of Payment, confirm/place order with Restaurant.
  4. On confirmation of order from Restaurant, initiate scheduling of Food Delivery.
  5. Notify the end user with success message and the time of delivery (this is important, don’t forget this 😃)
  6. And finally, update the status of the Order as Confirmed in the Database.
  1. It is assumed that the complete order flow — either success or failure will complete in less than 30 seconds, which is the hard limit timeout for an AWS API Gateway endpoint. This is a big risk, and we will have to handle the request in asynchronous way.
  2. If one of the downstream service invocations fails because of some temporary network glitch or because of throttling issue, the retry logic has to be configured in the New Order endpoint. Adds complexity to the business logic.
  3. If any of the step execution in the business flow fails, then all the steps for rollback needs to be handled, making the New Order endpoint more complex to deal with.
  4. If YAFDP system becomes a great success, and the inflow request for placing orders is way higher than what could be handled by downstream systems. For example — If Payment service integrates with 3rd Party Application which is not as scalable as the YAFDP platform is then the overall volume handling capacity of the system is dependent on the Payment Service volume handling capacity.
Approach 2— Place New Food Delivery Order
  1. Added SQS in the system which is integrated with API Gateway New Order endpoint. When Gateway receives new order request, it adds the request to the SQS and immediately returns unique SQS ID back to the caller for tracking purpose. SQS is highly scalable, hence system is much more scalable now in terms of accepting the orders. Rate of processing of the orders will still be dependent on the least performing service.
  2. Added AWS Serverless service Step Functions as an Orchestrator for New Order Business flow. Error handling and retries logic is managed by Step Functions. So, the Lambda functions (Microservices) becomes light on code and just need to focus on the business logic and nothing else.
  3. Create New Order Lambda is configured with AWS SQS as trigger point. AWS Lambda service does a Long Poling on the SQS and if there are items to be processed, it sends the items to the New Order Lambda for processing. By default, Lambda service reads items from SQS in batch of 5 with every batch having x number of items where x is a configurable parameter.
  4. AWS Lambda automatically increases the number of batches to be read from the SQS to scale the processing of the items.
  1. Adding Asynchronous event submission flow between API Gateway and New Order Microservice Lambda.
  2. Using Saga Orchestrator Pattern for handling long running business flow for New Order Creation — using AWS Serverless service Step Functions.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Naresh Waswani

Naresh Waswani

#AWS #CloudArchitect #CloudMigration #Microservices #Mobility #IoT