Serverless Patterns: Fan-Out, Choreography, and Orchestration

As serverless applications grow beyond single functions, you need architectural patterns to coordinate multiple services. This lesson covers three fundamental patterns — fan-out, choreography, and orchestration — along with practical implementations using AWS services.

---

Why Patterns Matter

A single Lambda function responding to an API Gateway request is straightforward. But real-world applications require:

• Processing a single event in multiple ways simultaneously
• Coordinating multi-step workflows with error handling and retries
• Decoupling services so they can evolve independently
• Handling failures gracefully without losing data

The patterns in this lesson address these challenges.

---

Pattern 1: Fan-Out

Fan-out distributes a single event to multiple consumers for parallel processing.

                    +---> Lambda A (resize image)
                    |
Event (S3 upload) --+--> Lambda B (extract metadata)
                    |
                    +---> Lambda C (virus scan)
                    |
                    +---> Lambda D (update database)

Implementation with SNS

SNS is the simplest fan-out mechanism — publish once, deliver to many:

# SAM Template
Resources:
  OrderTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: order-events

  SendConfirmationFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/sendConfirmation.handler
      Events:
        OrderPlaced:
          Type: SNS
          Properties:
            Topic: !Ref OrderTopic

  UpdateInventoryFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/updateInventory.handler
      Events:
        OrderPlaced:
          Type: SNS
          Properties:
            Topic: !Ref OrderTopic

  NotifyWarehouseFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/notifyWarehouse.handler
      Events:
        OrderPlaced:
          Type: SNS
          Properties:
            Topic: !Ref OrderTopic

Implementation with EventBridge

EventBridge provides more sophisticated routing with content-based filtering:

// Rule 1: Route high-value orders to fraud check
{
  "source": ["myapp.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "total": [{ "numeric": [">=", 500] }]
  }
}

// Rule 2: Route all orders to analytics
{
  "source": ["myapp.orders"],
  "detail-type": ["OrderPlaced"]
}

// Rule 3: Route international orders to customs
{
  "source": ["myapp.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "country": [{ "anything-but": "GB" }]
  }
}

SNS vs EventBridge for Fan-Out

Feature	SNS	EventBridge
Filtering	Basic attribute filtering	Rich content-based filtering
Targets	Lambda, SQS, HTTP, Email, SMS	Lambda, SQS, Step Functions, API destinations, 20+ targets
Schema registry	No	Yes
Archive and replay	No	Yes
Cross-account routing	Manual	Built-in
Cost	$0.50 per million messages	$1.00 per million events
Best for	Simple fan-out	Complex routing and event-driven architectures

---

Pattern 2: Choreography

In choreography, services react to events independently — there is no central coordinator. Each service performs its task and emits an event for the next step.

Order Service          Payment Service        Shipping Service
    |                       |                       |
    |-- OrderPlaced ------->|                       |
    |                       |-- PaymentProcessed -->|
    |                       |                       |-- ShipmentCreated
    |                       |                       |
    |<-- OrderUpdated ------|<-- StatusUpdated -----|

Implementation

// Order Service — publishes OrderPlaced event
export const createOrder = async (event) => {
  const order = JSON.parse(event.body);
  await saveOrder(order);

  await eventBridge.send(new PutEventsCommand({
    Entries: [{
      Source: 'myapp.orders',
      DetailType: 'OrderPlaced',
      Detail: JSON.stringify({ orderId: order.id, total: order.total }),
    }],
  }));

  return { statusCode: 201, body: JSON.stringify(order) };
};

// Payment Service — reacts to OrderPlaced, emits PaymentProcessed
export const processPayment = async (event) => {
  const order = event.detail;
  const result = await chargeCustomer(order);

  await eventBridge.send(new PutEventsCommand({
    Entries: [{
      Source: 'myapp.payments',
      DetailType: 'PaymentProcessed',
      Detail: JSON.stringify({ orderId: order.orderId, paymentId: result.id }),
    }],
  }));
};

// Shipping Service — reacts to PaymentProcessed
export const createShipment = async (event) => {
  const payment = event.detail;
  await scheduleShipment(payment.orderId);
};

Choreography Trade-offs

Advantage	Disadvantage
Services are fully decoupled	Hard to see the full workflow at a glance
Each service can be deployed independently	Debugging distributed flows is challenging
Easy to add new consumers	No single place to handle compensation/rollback
Scales naturally	Event ordering can be complex

---

Pattern 3: Orchestration with AWS Step Functions

Orchestration uses a central coordinator — AWS Step Functions — to manage the workflow. The orchestrator defines the sequence, handles errors, and manages retries.