A client application makes a request to an API Gateway endpoint.
The API Gateway uses a service connection (with optional transformation using VTL) to send the event to an SQS Queue directly.
If the message is successfully received, the SQS Queue will return an "ack" to the API Gateway, which will return a success message to the Client.
A Lambda Function is subscribed to the SQS Queue and polls it for new messages. When a new message is detected, the Lambda function is invoked synchronously.
The Lambda Function processes the message, connects to your RDS database, and attempts to perform your SQL operation.
If successful, the database returns a response to your function, and the message is removed from the SQS Queue.
If the database call fails (because it's throttled or there is another error), the Lambda function will return the batch of messages to the SQS Queue.
If the messages have been returned to the SQS Queue multiple times and exceeds the Maximum Receives count, the redrive policy will move the message to the specified Dead Letter Queue (DLQ).
The client can be a web browser, an application, or even another service in AWS.
Amazon API Gateway is a service that lets you route API requests. A POST route handles webhook requests.
An SQS Queue stores messages from the Lambda Function, adding durability and scalability to your request.
A "throttled" Lambda function has the function concurrency set to a number that will ensure that SQS Queue messages are not processed too quickly and overwhelm downstream systems.
An RDS Cluster with only 90 connections available. We want to avoid overwelming this database if we get a spike in traffic.
SQS Queue used as a Dead Letter Queue to capture failed batches.