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 — Covers Placing New Food Delivery Order using Choreograph Saga Event Driven Pattern.
Part 5 (This blog, last in the series) — Using Serverless stack for designing Notification Service.
Team N is responsible for designing a Notification Service which can deliver notifications to the end users of YAFDP Platform. To start with, the notifications can be over SMS and Email, but the service should be extensible to add more channels should there be a need.
Some of the additional requirements they have is as follows —
- Notification service can be leveraged by different applications running in the Organization and hence there should be an option to control the Rate limit should there be a need
- Service endpoint should be secured
- Service should be scalable
- Should be open for extension
With the requirements mentioned above, the solution that automatically comes into mind is using the Storage First Pattern with AWS API Gateway.
Storage First pattern is the approach where API Gateway directly puts events/messages into one of the Storage like DynamoDB, SQS, Event Bus, etc. without processing it.
And below is the solution that Team N comes up with —
Key points of the Design are —
- Leveraged AWS API Gateway to have support for Rate Limiting.
- Token based Lambda Authorizer for ensuring that only authenticated requests are allowed. End clients shall be issued unique Application ID and Secret which needs to be passed in the Authorization Header when making API Gateway request to send notification.
- Leveraged AWS SQS Message Broker with Storage First Pattern. This ensures that System can accept notification messages for delivery without throttling the end client requests and can then process the messages based on the scalability supported by the downstream applications. And yes, there will be SLAs around delivery of notifications in real time, and it would require additional thought process 😏. I have not considered the same for simplicity purpose.
- Instead of Lambda handlers directly saving processed message data to DynamoDB, SQS is being introduced to buffer the data and then save it in DynamoDB as per Write Capacity Unit (WCU) configured for it.
- System is highly extensible. Should there be a need to add additional delivery channel, let’s say Mobile Push Notification, a new SQS and Lambda Handler can be added without impacting the existing system.
Team N got this reviewed by other Teams who will be using the Notification Service, and they requested to have mechanism for providing status of the processed notifications.
Team N now thinks of the same and comes up with below options for providing status of the processed messages if requested by the client applications —
- Using AWS Simple Notification Service (SNS) service for making HTTP calls to the Callback URL configured for the specific client application. With this option, client has to ensure that HTTP endpoint is always available else there are chances of message status getting lost. The callback URL can be subscribed in the SNS Topic.
- Lambda handler to deliver status of the processed messages to the calling application’s AWS Event Bridge service. In this approach, Notification service is responsible to delivering the message status to the Client’s AWS Event Bridge and then client application can configure Lambda handlers or other consumer processes to process the event.
That’s it for this blog and in-fact for the entire series of AWS Serverless and Microservices.
Hope you enjoyed the entire series ☺️.