Serverless Patterns

Event-driven architecture — common serverless design patterns using Lambda, API Gateway, Step Functions, EventBridge, SQS, and DynamoDB.

Overview

Serverless patterns are architecture blueprints that combine fully managed, event-driven services — Lambda, API Gateway, Step Functions, EventBridge, SQS, SNS, and DynamoDB — to build applications without provisioning or managing servers.

Core Serverless Services

Service	Role in Serverless Architecture
Lambda	Compute — runs code in response to events
API Gateway	HTTP entry point — REST, HTTP, and WebSocket APIs
Step Functions	Orchestration — coordinate multi-step workflows
EventBridge	Event routing — content-based filtering and fan-out
SQS	Buffering — decouple producers and consumers
SNS	Notification — fan-out to multiple subscribers
DynamoDB	Database — single-digit millisecond NoSQL storage
S3	Storage — object store and event source
Cognito	Authentication — user pools and identity federation
AppSync	GraphQL API — managed real-time and offline data sync

Pattern 1: Synchronous API

Client → API Gateway → Lambda → DynamoDB
                ↑                    │
                └────── Response ────┘

Simplest serverless pattern for CRUD operations
API Gateway handles auth (Cognito / Lambda authorizer), throttling, and caching
Lambda processes the request and interacts with DynamoDB
Response returns synchronously to the client

Pattern 2: Asynchronous Processing

Client → API Gateway → SQS Queue → Lambda (consumer) → DynamoDB
              │
              └── 202 Accepted (immediate)

API Gateway sends message to SQS and returns immediately
Lambda polls SQS and processes messages at its own pace
Decouples request acceptance from processing — handles traffic spikes
DLQ captures failed messages for retry or investigation

Pattern 3: Fan-Out

Event Source (S3, API Gateway)
    → SNS Topic
        ├── SQS → Lambda (image resize)
        ├── SQS → Lambda (metadata extract)
        └── Lambda (notification)

Single event triggers multiple independent processing paths
Each SQS queue provides buffering and independent failure handling
SNS filter policies route specific events to specific subscribers

Pattern 4: Event-Driven Pipeline

S3 (object uploaded)
    → EventBridge Rule
        → Step Functions
            ├── Lambda (validate)
            ├── Lambda (transform)
            ├── Lambda (load to DynamoDB)
            └── SNS (notify completion)

S3 event triggers EventBridge, which starts a Step Functions workflow
Each step has built-in retry and error handling
Step Functions provides visual monitoring and execution history

Pattern 5: Choreography vs Orchestration

Approach	Description	AWS Service
Choreography	Services react to events independently; no central coordinator	EventBridge, SNS, SQS
Orchestration	Central coordinator manages the workflow sequence	Step Functions

Choreography:
  OrderService → publishes "OrderCreated"
  PaymentService → reacts to "OrderCreated"
  InventoryService → reacts to "OrderCreated"
  (each service acts independently; no coordinator)

Orchestration:
  Step Functions → calls PaymentService
                 → calls InventoryService
                 → calls ShippingService
  (central workflow controls the sequence)

When to Choose

Criteria	Choreography	Orchestration
Simple event reactions	Preferred	Overkill
Complex multi-step with ordering	Harder to manage	Preferred
Need visibility of full workflow	Requires custom correlation	Built-in with Step Functions
Service independence	Higher (loose coupling)	Lower (coordinator dependency)
Error handling	Each service manages its own	Central retry and catch logic

Pattern 6: Data Lake Ingestion

Kinesis Data Stream (real-time)
    → Lambda (transform)
        → S3 (data lake)
            → Athena (query)

DynamoDB Streams
    → Lambda (aggregate)
        → S3 / OpenSearch

Kinesis or DynamoDB Streams provide real-time change feeds
Lambda transforms and delivers to S3 or analytics services
Fully serverless — no cluster management

Pattern 7: Scheduled Tasks

EventBridge Scheduler (cron)
    → Lambda
        → Generate report → S3
        → Clean up old data → DynamoDB TTL
        → Send digest email → SES

Replaces cron jobs on EC2 instances
EventBridge Scheduler supports one-time and recurring schedules
Lambda handles the task logic; no server to maintain

Serverless Anti-Patterns

Anti-Pattern	Problem	Alternative
Lambda for long-running tasks	15-minute timeout; expensive for compute-heavy work	ECS Fargate, Step Functions
Lambda for persistent connections	WebSocket needs stateful connection management	API Gateway WebSocket, AppSync
Monolithic Lambda	Single large function handling everything	Break into single-purpose functions
Synchronous chains	Lambda → Lambda → Lambda (latency, coupling)	SQS between steps or Step Functions
Cold start-sensitive workloads	Latency-critical paths with infrequent invocations	Provisioned Concurrency, Fargate

Quick Reference

Pattern	Key Services	When to Use
Synchronous API	API GW + Lambda + DynamoDB	Simple CRUD, low-latency response needed
Async Processing	API GW + SQS + Lambda	Decouple ingestion from processing
Fan-Out	SNS + SQS + Lambda	One event, multiple independent consumers
Event Pipeline	EventBridge + Step Functions + Lambda	Multi-step processing with orchestration
Choreography	EventBridge + services react	Loosely coupled event-driven microservices
Orchestration	Step Functions	Complex ordered workflows with retries
Data Lake Ingestion	Kinesis/DDB Streams + Lambda + S3	Real-time analytics pipeline
Scheduled Tasks	EventBridge Scheduler + Lambda	Replace cron jobs

AWS Implementation Options

Requirement	Serverless Option	Non-Serverless Alternative
HTTP API backend	API Gateway + Lambda	ALB + ECS / EC2
Asynchronous task queue	SQS + Lambda	SQS + ECS worker
Workflow orchestration	Step Functions	ECS + custom state management
Event routing	EventBridge	Amazon MQ, self-managed Kafka
Real-time data processing	Kinesis + Lambda	Kinesis + KCL on EC2
NoSQL database	DynamoDB (On-Demand)	DynamoDB (Provisioned), MongoDB
File processing	S3 event → Lambda	S3 event → ECS task

SAA/SAP Exam Tips

SAA Tip: "Fully serverless" or "no infrastructure management" → Lambda + API Gateway + DynamoDB is the standard serverless stack. Add SQS for decoupling and Step Functions for orchestration.

SAP Tip: Know when serverless is NOT the right answer: persistent connections (use WebSocket API or AppSync), compute-heavy tasks > 15 min (use Fargate or Batch), and latency-sensitive workloads with cold start issues (use Provisioned Concurrency or containers).

SAP Tip: Choreography (EventBridge) vs Orchestration (Step Functions) is a common exam question. Choreography for simple event reactions with loose coupling; orchestration when execution order, error handling, and visibility matter.

AWS Lambda — core compute service for serverless
Amazon API Gateway — HTTP entry point for serverless APIs
AWS Step Functions — orchestration for multi-step workflows
Amazon EventBridge — event routing for choreography patterns
Amazon SQS and SNS — messaging for decoupling and fan-out
Well-Architected Framework — serverless aligns with Performance Efficiency and Sustainability pillars

Serverless Patterns

On this page