Why does the API respond before the work is done?

Because the first Lambda does nothing slow. It checks the input, calls SendMessage and returns, so the caller has an acknowledgment before the real work has started. If the worker is down the message waits on the queue (four days by default, up to fourteen), and if a worker run fails the message becomes visible again and is retried. The durability is what you are paying for.

How is this different from the pub/sub fan-out example?

A queue hands each message to one consumer, and the message is gone once that consumer deletes it. SNS copies each event to every subscriber. Use SQS when one worker should handle each job, and SNS when several systems each need their own copy of the event.

Examples / AWS

Why put SQS between two Lambdas?

Updated 15 September 2026

API Gateway -> Lambda -> SQS -> Lambda Worker -> DynamoDB. The first Lambda checks the request, puts a message on SQS and returns; the worker is invoked from the queue and writes to DynamoDB whenever it gets there. One animation pass carries the message across all five boxes, and the queue in the middle is where the caller stops waiting.

Queue Worker Diagram: API Gateway, SQS and a Lambda Consumer. The first Lambda only enqueues, so the API answers at once and the worker takes as long as it needs. 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, WebP or MP4 video, or a still PNG or PDF, every format free. WebM and PNG export here; the rest are in the app after a free sign-up. Every format embeds this text, so the file can be read back into the editor.

WHAT IT SHOWS

The queue splits the request in two, and the caller only waits for the first half.

Up front, the first Lambda does as little as possible: check the input, put a message on SQS, return. That is quick. The caller has an answer long before the work is done. Afterwards the Lambda Worker is invoked from the queue and does the slow part. Whatever it produces goes to DynamoDB. Neither function calls the other. One writes to the queue and the other is fed from it, and either can be down for a while without the other noticing.

Where failure shows up moves too. In a synchronous chain a slow DynamoDB write or a slow third-party call makes the API slow, and past 29 seconds API Gateway gives up on the integration and the caller gets a 504 (29 seconds is the default integration timeout for a REST API). With the queue in the middle the same slow dependency makes the queue deeper, and depth is a CloudWatch metric (ApproximateNumberOfMessagesVisible) you can graph and alarm on while the API keeps answering. A timeout is a support ticket.

On the canvas, one pass takes the message across all five boxes, so the queue looks like one more hop, and it helps to read it knowing that once the message is on SQS the caller has already been answered and the last two hops happen after that, whenever the worker gets to them. Messages wait on the queue as long as they have to, four days by default and up to fourteen if you set it, and a failed worker run puts a message back for another attempt.

These five boxes fit order processing, transcoding, report generation, batch email and anything else where the work takes longer than a caller wants to wait. What varies is the worker’s run time. Lambda caps that at 15 minutes.

QUESTIONS

Why does the API respond before the work is done?: Because the first Lambda does nothing slow. It checks the input, calls SendMessage and returns, so the caller has an acknowledgment before the real work has started. If the worker is down the message waits on the queue (four days by default, up to fourteen), and if a worker run fails the message becomes visible again and is retried. The durability is what you are paying for.
How is this different from the pub/sub fan-out example?: A queue hands each message to one consumer, and the message is gone once that consumer deletes it. SNS copies each event to every subscriber. Use SQS when one worker should handle each job, and SNS when several systems each need their own copy of the event.

MORE AWS PATTERNS

Serverless REST API diagram

API Gateway takes the request, Lambda runs the code and DynamoDB keeps the data.

API Gateway -> Lambda -> DynamoDB

Pub/sub fan-out diagram

SNS hands the same event to two Lambdas and a queue at the same time.

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

Event pipeline diagram

The same event goes down a three-hop chain and straight into S3 at the same time.

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.