Designing Event-Driven Architecture

The main objective of this blog post is to get you started on thinking serverless. You will get familiar with key Amazon Web Services and patterns that will be used to design event-driven architectures.

Serverless represents abstracting your computing infrastructure to the point that you have no responsibilities for the servers on which your code runs. One of the key benefit of Serverless is, you pay for the amount of time your code runs. You are not paying for the idle time.

The idea behind Event-Driven Architectures is use of events to communicate between decoupled services, use events to trigger or invoke the service. A simple example to event is, a simple change or update in a cart of an e-commerce website.

Asynchronous Pattern

Use of asynchronous patter can be more beneficial for some workloads than synchronous pattern. Asynchronous patterns eliminates the downstream issues, need of immediate response and no built-in retries.

In the above scenario, introducing a SQS between API Gateway and Lambda makes the decoupling of synchronous connection. The benefit of this approach is,

• API request can respond to the client immediately without waiting for the Lambda execution.
• SQS has built in retry and ability to configure dead-letter queue for the message that could not be processed

Let’s assume that, client has triggered order creation. The order creation request comes in, the API Gateway sends it to Amazon SQS and gets a message ID back to the client for tracking it. Lambda pools to the queue and execute the message in the queue per batch. ( The order of execution in the queue can be configured).

Note: By default Lambda process 05 batches at a time and sends each batch to an invocation of Lambda function.

You can use both standard and First-In-First-Out (FIFO) SQS queues as a Lambda event source

Step Functions for Orchestrating

You can orchestrate any AWS service using Step Functions service integrations. Service integrations allow you to create calls to AWS services and include the response into your workflow.

Use of Step Functions to do the business logic

Patterns for Communication Status Updates

1. Client pooling pattern

Client pool way of communicating status updates

• Introduce status and getResults endpoints to retrieve the status of the order
• /status endpoint allows the client to get the update from Dynamodb
• /getResult endpoint gives the information about the order

Note, there are couple of new endpoints created for the client to do polling of status check.

This approach has benefit of asynchronous flow however, increases latency by waiting for the status check pooling and increased additional endpoints

2. Webhook pattern with Amazon SNS

example — webhook pattern for status update

3. Web Socket with AWS AppSync

Websocket with AWS AppSync