AWS Serverless and Microservices — Part 4

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 — Covers approach of sending the status of asynchronous task submission, in our case New Food Order Placement, to the client.

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

Part 5 — Using Serverless stack for designing Notification Service.

In Part 2, we implemented New Food Delivery Order Use case using Orchestration Saga Pattern. In this blog, we will implement the same flow with Choreograph Saga Pattern using AWS Serverless Stack. The pattern is called as Event Driven Pattern.

Choreograph based Saga is an Event based pattern in which Services emit events as and when an activity is performed, and other services listen for the events they are interested in. And based on the event received, the service performs the next activity and then it further emits events. It’s an extreme way of Loose coupling between Services.

To get more details on this pattern, do take a look at the below blog —

Sagas in Microservices

When working with Event based system, the first thing is to identity all the events which can flow into the system. Let’s identity the same for our Use case —

1. Order_Initiated
2. Payment_Success
3. Payment_Failed
4. Restaurant_Confirmed_Order
5. Restaurant_Rejected_Order
6. Delivery_Scheduled

The list of events mentioned above covers all the possibilities of activities that can happen while placing a New Food Delivery Order.

Once the events are identified, the next step if to identity which Service shall be interested in which events. For our Use case —

1. Payment Service shall be interested in Order_Initiated event. When initiated, it will initiate the Payment process.
2. Restaurant Service shall be interested in Payment_Success event. On receiving the event, it will initiate the Order confirmation flow with Restaurant.
3. Delivery Service shall be interested in Restaurant_Confirmed_Order event. Once the event is received, it will schedule delivery of the order.
4. Payment Service shall be interested in Restaurant_Rejected_Order event. If the Order is rejected by the Restaurant because of whatever reason, Payment service needs to initiate the Payment Refund process.
5. Order Service shall be interested in all the events. Reason is — it needs to update the status of the Order in its Database.
6. Notification Service shall be interested in almost all the events as the service needs to inform the end user about every status change in the Order (Wow…Team is thinking about good User Experience 😏)

AWS offers Event Bridge, a serverless event bus that makes it easy to connect applications together using data from your own applications. It is a highly available service, helps in simplified event routing and also helps to improve the overall availability of the system. For more details on Event Bridge, take a look at below link —

Amazon EventBridge | Event Bus | Amazon Web Services

Captured below is the sequence of events emitted by different services for the New Food Order Delivery use case —

1) New Order Placement — Order_Initiated event emitted

2) New Order Placement — Payment_Success event emitted

3) New Order Placement — Restaurant_Confirmed_Order event emitted

4) New Order Placement — Delivery_Scheduled event emitted

The New Order Placement flow above highlights how different services integrate with each other without actually knowing about them. All they care about is emit the correct event when the activity occurs.

With Event Driven Architecture, it is also very easy to add new features. Let’s say, we now want to give Loyalty points to the user when a New Order is placed. For this to implement, all we need to do is create a new service, let’s call it as Loyalty Service and have it subscribed to the Restaurant_Confirmed_Order event. Once the Order is confirmed, Loyalty service adds points against the end user.

That’s it for this blog. In the next and final blog of the series, I shall cover designing Notification Service.

Till then, Cheers!!!