Event-Driven Serverless Patterns

Patterns are guides, not silver bullets

Serverless is both influenced by decades of prior patterns (GoF, enterprise integration, microservices) and generative of new ones. The substrate of every pattern is resilience, idempotency, and loose coupling built over an event-driven backbone — where immutable events (something that already happened) flow between decoupled services via producers, consumers, and event carriers (buses/brokers).

The event bus: Amazon EventBridge

EventBridge is the fully managed serverless event bus — it ingests, filters, transforms, and routes events to up to five targets per rule. Key facts that shape design: at-least-once delivery with no ordering guarantee, retries up to 24 hours then a dead letter queue (DLQ), and a 256 KB max event payload. Auxiliary features include archive and replay, a schema registry, EventBridge Scheduler, and EventBridge Pipes (one source → one target with filter/transform/enrich).

graph TD
P["Producer<br/>(publish-and-forget)"] --> SF["Storage-first<br/>(store before process)"]
SF --> EB["EventBridge bus<br/>(filter + route)"]
EB --> C1["Consumer A<br/>(idempotent)"]
EB --> C2["Consumer B<br/>(idempotent)"]
EB -. undeliverable .-> DLQ["Dead letter queue"]
C1 --> R["Event relay<br/>(emit new event,<br/>never modify-and-relay)"]

A catalog of named patterns

• Storage-first pattern (Eric Johnson) — “store first, process after.” Persist incoming data in SQS, Kinesis, S3, or DynamoDB before computing, so async decoupling never loses data; choice depends on retention. Enables idempotency and audit logs.
• Strangler fig pattern (Fowler) — incrementally migrate legacy to serverless, strangling it piece by piece (redirect data flows into a common S3 bucket; run old and new API routes in parallel behind an API Gateway or BFF façade).
• Circuit breaker pattern — fail fast when a dependency is unhealthy to avoid retry storms and runaway cost. States: closed, open, half-open. Lambda has none built-in; implement with a status check in SSM/DynamoDB or a dedicated status service, with store-and-replay while open.
• Functionless integration pattern — connect services with native integrations and IaC instead of “transport” Lambdas (API Gateway VTL, Step Functions direct + AWS SDK integrations, EventBridge API destinations). Benefits: less code, fewer failure points, fewer IAM policies, lower cost. Keep a function where you need detailed or censored logs.
• Gatekeeper event bus pattern — a dedicated custom bus guarding a bounded-context boundary, controlling event outflow (only domain events leave) and inflow (only required events enter), isolating encryption, cross-account routing, and DLQs.

Choreography vs. orchestration

• Choreography — no central controller; services react to events independently (the dancers analogy). Considerations: event loss (retries + DLQ), duplicates, action sequencing, distributed resiliency, and traceability via an immutable trace_id plus AWS X-Ray.
• Orchestration — a central conductor coordinates steps, branches, and collation. AWS Step Functions is the orchestrator; chaining Lambdas via synchronous invocations is an antipattern. Types: in-service, cross-service, and distributed (long-running async via task tokens and the callback pattern).
• Saga pattern — consistency across distributed transactions as atomic local steps, undone by compensating transactions, with pivot transactions marking the point of no return.

graph LR
subgraph CH["Choreography (no controller)"]
  S1["Service A"] -- event --> S2["Service B"]
  S2 -- event --> S3["Service C"]
end
subgraph OR["Orchestration (central conductor)"]
  SF["Step Functions"] --> A1["Service A"]
  SF --> A2["Service B"]
  SF --> A3["Service C"]
end

See also

• What is serverless — the managed services these patterns compose.
• Serverless-first design — event-driven-first as a prerequisite.
• Testing serverless — testing integration points and data contracts.

When to use it — and when not

Related topics