Serverless Event Flow Diagram

This sample follows one order through a serverless pipeline on AWS: API Gateway receives it, a small Lambda function validates it and drops it on an SQS queue, and a second Lambda function processes the queue in batches and stores the result in DynamoDB. Messages that keep failing are moved to a dead-letter queue (DLQ) and raise an alarm. The diagram shows both the happy path and where failures go.

This is an event-flow (architecture) diagram. UML covers software structure and behaviour; event-flow diagrams are the companion notation for asynchronous cloud pipelines, and the variant below shows the same flow as a UML sequence diagram.

1. The diagram

Order intake on AWS serverless Client POST /orders API Gateway REST, IAM/JWT auth Lambda ingest validate, enqueue SQS orders standard queue Lambda process batch size 10 DynamoDB Orders table SQS orders-dlq maxReceiveCount 3 CW alarm DLQ depth > 0 SNS on-call email / pager 1 2 3 4 5 PutItem (conditional) 202 Accepted failed ids 6 redrive after 3 receives Settings that make this flow safe - SQS visibility timeout = 6 x Lambda timeout - ReportBatchItemFailures on the event source mapping - Idempotent writes: condition attribute_not_exists(pk) - DLQ retention (14 days) longer than source queue - Messages may arrive twice or out of order (standard queue)
  1. Request. The client sends POST /orders. API Gateway authenticates it and invokes the ingest function (Lambda proxy integration).
  2. Validate. The ingest function checks the payload, rejecting bad input with a 400, so junk never reaches the queue.
  3. Enqueue. It calls SendMessage and returns 202 Accepted straight away. The client does not wait for processing.
  4. Consume. Lambda's event source mapping polls SQS and invokes the process function with up to 10 messages per batch, scaling out as the queue grows.
  5. Store. Each order is written with a conditional PutItem, so a duplicate delivery cannot create a second order.
  6. Fail safely. The function reports only failed message ids back. Those messages become visible again after the visibility timeout; after the third failed receive, SQS moves them to the DLQ, and a CloudWatch alarm notifies on-call through SNS.

2. How to read it

Notation used on this page Function Lambda, API Queue buffer, retries Data store final state Error path DLQ, alarm 1 step number synchronous call response failure / retry route

Read left to right for the happy path, then follow the red dashed arrows downward for failures. The queue is the key element: everything to its left is synchronous and fast, everything to its right is asynchronous and retried.

3. Variant: the failure path as a sequence diagram

Variant: the failure path as a UML sequence diagram Client API GW ingest fn SQS process fn DynamoDB DLQ POST /orders invoke SendMessage MessageId 202 202 Accepted loop [x3] poll: batch of 10 PutItem Throttling error batchItemFailures invisible until visibility timeout ends move to DLQ (receive count > 3)

The architecture view shows where a failed message goes; a UML sequence diagram shows when. The loop [x3] combined fragment makes the retry count explicit, and it is clear that the client already has its 202 long before the failure happens, which is exactly why the DLQ alarm is needed.

4. Pros, cons, and when to use

Pros

Cons

When to use

When not to use

5. Diagrams-as-code

The main flow in Mermaid:

flowchart LR
  client([Client]) -->|POST /orders| apigw[API Gateway]
  apigw -->|invoke| ingest[Lambda ingest]
  ingest -->|SendMessage| q[[SQS orders]]
  apigw -.->|202 Accepted| client
  q -->|batch of 10| proc[Lambda process]
  proc -->|conditional PutItem| ddb[(DynamoDB Orders)]
  proc -.->|batchItemFailures| q
  q -->|after 3 receives| dlq[[SQS orders-dlq]]
  dlq --> alarm[CloudWatch alarm] --> sns[SNS on-call]