Serverless Architecture Cheat Sheet

Design patterns, tradeoffs, and best practices for building event-driven serverless applications across cloud providers.

2 PagesIntermediateFeb 12, 2026

Fan-Out Pattern (AWS SAM/CloudFormation)

One event triggers multiple parallel downstream functions via SNS.

yaml

Resources:  OrderTopic:    Type: AWS::SNS::Topic  NotifyFn:    Type: AWS::Serverless::Function    Properties:      Handler: notify.handler      Events:        SNS:          Type: SNS          Properties:            Topic: !Ref OrderTopic  InventoryFn:    Type: AWS::Serverless::Function    Properties:      Handler: inventory.handler      Events:        SNS:          Type: SNS          Properties:            Topic: !Ref OrderTopic

Idempotent Function Handler

Guard against duplicate event delivery, common in serverless.

python

processed_ids = set()  # use durable store (e.g. DynamoDB) in productiondef handler(event, context):    request_id = event['requestId']    if request_id in processed_ids:        return {'statusCode': 200, 'body': 'already processed'}    # ... do the actual work ...    processed_ids.add(request_id)    return {'statusCode': 200, 'body': 'processed'}

Core Patterns

Key core patterns to know.

Function-as-a-Service (FaaS)- Short-lived, stateless functions triggered by events (Lambda, Cloud Functions, Azure Functions)
Event-Driven Architecture- Services communicate asynchronously via events rather than direct calls
Backend for Frontend (BFF)- API Gateway + Lambda tailored per client type (web, mobile)
Saga Pattern- Chain of local transactions with compensating actions for distributed rollback
Fan-out/Fan-in- Distribute work to many parallel functions, then aggregate results

Tradeoffs & Pitfalls

Key tradeoffs & pitfalls to know.

Cold Starts- Latency spike when a new execution environment initializes
Vendor Lock-in- Provider-specific triggers/APIs make migration harder
Statelessness- Functions must externalize state (DB, cache) since instances aren't persistent
Distributed Tracing- Essential for debugging across many short-lived, independently scaled functions
Execution Limits- Max duration, memory, and payload size constrain what a single function can do

Pro Tip

Design every serverless handler to be idempotent from day one — most event sources (SQS, SNS, EventBridge, Pub/Sub) guarantee at-least-once delivery, meaning duplicate invocations are a certainty, not an edge case.

Was this cheat sheet helpful?

GCP Compute Engine Cheat Sheet

Cloud Cost Optimization Cheat Sheet