Examples / AWS

Why put SQS between two Lambdas?

Updated

API Gateway -> Lambda -> SQS -> Lambda Worker -> DynamoDB: the first Lambda accepts the request and drops a message on SQS; the worker consumes it at its own pace and writes to DynamoDB. The animation shows the message crossing the queue, making the async boundary visible.
Queue Worker Diagram: API Gateway, SQS and a Lambda Consumer. Accept the request quickly, do the slow part somewhere else. Services drawn: API Gateway, Lambda, SQS, Lambda Worker, DynamoDB.
A still of the animation above. Every export embeds the diagram source.

THE TEXT THAT DRAWS IT

API Gateway -> Lambda -> SQS -> Lambda Worker -> DynamoDB

Edit it in the box above and the diagram redraws as you type. Export it as an animated GIF, WebM or WebP, or a still PNG. Every format embeds this text, so the file can be read back into the editor.

WHAT IT SHOWS

The queue is here to break the request in two. The first Lambda does only enough work to accept the job and put it on SQS, so the caller gets an answer in milliseconds. The Lambda Worker picks the message up afterwards and does the slow part, writing the result to DynamoDB.

The reason to draw this rather than describe it is that the queue changes the failure story, and the change is easy to state and hard to picture. Before the queue, a slow downstream dependency makes the API slow. After it, a slow dependency makes the queue deeper. Depth is survivable and observable; a timing-out API is neither.

Watching the message stop at the queue and continue a beat later is the part a static diagram cannot express. That pause is the architecture.

The same five boxes describe order processing, video transcoding, report generation and email sending. What varies is only how long the worker takes.

QUESTIONS

Why does the API respond before the work is done?
The first Lambda only validates and enqueues, so the caller gets an immediate acknowledgment. The queue guarantees the work happens even if the worker is briefly down. That guarantee, not speed, is why the pattern exists.
How is this different from the pub/sub fan-out example?
A queue delivers each message to one worker; SNS fan-out copies one event to every subscriber. Use a queue when work must happen exactly once, fan-out when several systems each need the event.

MORE AWS PATTERNS

Serverless REST API diagram

The request/response backbone of most serverless applications.

API Gateway -> Lambda -> DynamoDB

Pub/sub fan-out diagram

One event, several independent consumers, none of them waiting on each other.

SNS -> {Lambda Emailer, Lambda Analytics, SQS Archive}

Event pipeline diagram

One event bus feeding both a processing chain and a raw archive.

EventBridge -> {(SQS -> Lambda -> DynamoDB), S3}

Also on this site: RAG pipeline diagram, Multi-agent router diagram, ReAct tool-calling diagram, Human-in-the-loop diagram, MCP architecture diagram and Cloudflare Workers diagram. See all 10 patterns.

Chartado is a text-to-diagram tool: you type lines like A -> B, it draws the architecture and animates the flow.