Serverless Architecture Patterns

Serverless computing offloads infrastructure management to the cloud provider. You write functions or managed services, and AWS handles provisioning, scaling, patching, and high availability.

Serverless excels in these scenarios:

Event-driven workloads: S3 object uploads triggering image processing, DynamoDB streams driving analytics, or SQS messages triggering order processing. The function runs only when an event arrives—you pay nothing at rest.

Variable or unpredictable traffic: An e-commerce API that handles 100 requests per minute normally but 10,000 during a flash sale. Lambda scales automatically from zero to thousands of concurrent executions without pre-provisioning.

Rapid prototyping: Deploy a REST API with API Gateway + Lambda in minutes. No EC2 instances to manage, no load balancers to configure. Focus on business logic, not infrastructure.

Microservice decomposition: Each Lambda function handles one responsibility—one function processes payments, another sends emails, another generates reports. Independent scaling, deployment, and failure isolation.

Serverless may not fit: long-running processes (Lambda has a 15-minute timeout), workloads requiring consistent high throughput (provisioned concurrency costs negate savings), or applications needing specific OS-level configurations. For these, containers on ECS/EKS or EC2 are better choices.

Cost model: You pay per request and per millisecond of compute. A function handling 1 million requests at 200ms each costs roughly $0.40. Compare this to running an EC2 instance 24/7 at $50+/month—even if that instance sits idle 90% of the time.

Fan-out/fan-in distributes work to multiple parallel workers and aggregates results. It's the map-reduce of serverless.

Fan-out: A Lambda function publishes messages to an SNS topic or invokes multiple Lambda functions in parallel. Each worker processes a subset of the work independently.

Fan-in: As workers complete, they write results to DynamoDB, S3, or an SQS queue. A coordinator function or Step Functions state machine collects all results and performs the final aggregation.

Real-world example—a video transcoding service:

1. User uploads a video to S3
2. A Lambda function (fan-out) splits the video into 10 segments
3. 10 parallel Lambda functions each transcode one segment
4. A Step Functions state machine waits for all 10 to complete (fan-in)
5. A final Lambda function merges segments and notifies the user

Implementation with Step Functions:

{
  "Type": "Map",
  "ItemsPath": "$.segments",
  "MaxConcurrency": 10,
  "Iterator": {
    "StartAt": "Transcode",
    "States": {
      "Transcode": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:us-east-1:123456789012:function:transcode-segment"
      }
    }
  }
}

The Map state iterates over a list and runs the same workflow for each item, with configurable concurrency.

The Saga pattern manages distributed transactions across multiple services without two-phase commit. Each step has a compensating action that undoes it if a later step fails.

Choreography saga: Each service listens for events and decides what to do next. An order service publishes OrderCreated, the inventory service reserves stock and publishes StockReserved, the payment service charges and publishes PaymentProcessed. If payment fails, it publishes PaymentFailed, triggering the inventory service to release the stock.

Orchestration saga: A central orchestrator (Step Functions) controls the sequence. It calls each service in order and handles compensations if any step fails:

{
  "StartAt": "ReserveInventory",
  "States": {
    "ReserveInventory": {
      "Type": "Task",
      "Resource": "arn:aws:states:::ecs:runTask",
      "Next": "ProcessPayment",
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "ReleaseInventory"
      }]
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:process-payment",
      "Next": "ShipOrder",
      "Catch": [{
        "ErrorEquals": ["States.ALL"],
        "Next": "RefundPayment"
      }]
    }
  }
}

Use choreography for simple, loosely coupled services. Use orchestration when the workflow is complex, has many steps, or requires centralized visibility.

The Strangler Fig pattern incrementally replaces a monolith with microservices without a big-bang migration. Route traffic to the new service for specific paths while the rest goes to the monolith.

Implementation with API Gateway:

# Route /api/v2/orders to new Lambda service
paths:
  /api/v2/orders:
    x-amazon-apigateway-integration:
      uri: arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/new-order-service/invocations
  /api/v2/orders/{id}:
    x-amazon-apigateway-integration:
      uri: arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/new-order-service/invocations
  # Everything else routes to monolith
  /{proxy+}:
    x-amazon-apigateway-integration:
      uri: http://monolith-internal-alb.amazonaws.com/{proxy}

Over time, migrate more routes until the monolith is empty and can be decommissioned.

CQRS (Command Query Responsibility Segregation) separates read and write models. Commands (create, update, delete) go to a write database (DynamoDB). Queries (read, search) go to a read-optimized store (ElastiCache, OpenSearch). An event bridge (EventBridge or DynamoDB Streams) keeps the read model in sync.

Benefits: read and write scales independently, read models can be denormalized for query performance, and write models enforce business rules without read concerns. The trade-off is eventual consistency—read models may lag behind writes by milliseconds to seconds.