Serverless Event-Driven Architecture Patterns

## ROLE

You are a serverless architecture specialist with deep expertise in event-driven systems across AWS Lambda, Azure Functions, and Google Cloud Functions. You have designed systems processing millions of events per day using managed event buses, queues, and stream processors. You understand the trade-offs between choreography and orchestration, have implemented complex saga patterns for distributed transactions, and have solved the hardest problems in serverless: cold starts, observability gaps, testing distributed flows, and managing state in stateless compute.

## OBJECTIVE

Design a complete serverless event-driven architecture for [APPLICATION DOMAIN: e-commerce order processing / IoT data pipeline / real-time analytics platform / content moderation system / financial transaction processing / SaaS multi-tenant backend / healthcare event processing]. The system runs on [CLOUD PROVIDER: AWS / Azure / GCP / multi-cloud] and must handle [THROUGHPUT: hundreds / thousands / millions] of events per [TIME UNIT: second / minute / hour] with [LATENCY REQUIREMENT: sub-second / under 5 seconds / near-real-time / batch-tolerant] end-to-end processing.

## TASK: EVENT-DRIVEN ARCHITECTURE DESIGN

### Event Taxonomy & Schema Design

Define the complete event catalog for [APPLICATION DOMAIN]. For each event:

**Event Naming Convention:** Use past-tense domain events following the pattern [BOUNDED_CONTEXT].[ENTITY].[ACTION_PAST_TENSE] — for example, Orders.Order.Placed, Payments.Payment.Captured, Inventory.Stock.Depleted. List [NUMBER: 10-15] core domain events that drive the system's primary workflows.

**Event Schema:** Design each event using CloudEvents specification (or [ALTERNATIVE: custom envelope / AsyncAPI]) with these fields: id (UUID v4), source (originating service URI), type (event name), specversion, time (ISO 8601), datacontenttype, and data payload. The data payload for each event must include all information a consumer needs without requiring callback queries to the producer — this is critical for decoupling. Provide a complete JSON schema for [NUMBER: 3-5] of the most important events with field descriptions, required/optional designations, and example payloads.

**Schema Registry & Evolution:** Implement schema versioning using [APPROACH: embedded version field / content-type versioning / schema registry (Confluent / AWS Glue / custom)]. Define rules for backward-compatible changes (adding optional fields, adding new event types) versus breaking changes (removing fields, changing types) and the migration strategy for each.

### Event Routing & Processing Topology

Design the event flow architecture using this topology:

**Event Bus / Broker:** Select and configure [SERVICE: Amazon EventBridge / Azure Event Grid / Google Eventarc / Apache Kafka (MSK/Confluent Cloud) / custom] as the central event router. Define routing rules that direct events to appropriate consumers based on event type, source, and content-based filtering on [FIELD: customer tier / region / amount threshold / custom attribute]. Explain the delivery guarantees (at-least-once vs. exactly-once) and how your design handles each.

**Function Topology:** Map each event to its consuming function(s). For [APPLICATION DOMAIN], design these processing patterns:

1. **Fan-Out Pattern:** Event [EXAMPLE: Order.Placed] triggers parallel processing by [NUMBER: 3-5] independent functions (inventory reservation, payment initiation, notification dispatch, analytics recording, fraud check). Each function operates independently with its own error handling and retry policy.

2. **Pipeline Pattern:** Event [EXAMPLE: Image.Uploaded] triggers sequential processing through [NUMBER: 3-4] stages (validation -> transformation -> enrichment -> storage) using [CHAINING METHOD: event bus re-emission / Step Functions / Durable Functions / Cloud Workflows].

3. **Aggregation Pattern:** Multiple events [EXAMPLES: CartItem.Added, CartItem.Removed, Coupon.Applied] converge into a single materialized view or trigger a composite action when [CONDITION: all items confirmed / timeout reached / threshold met].

### Saga Pattern for Distributed Transactions

Implement the saga pattern for the most complex multi-step workflow in [APPLICATION DOMAIN]. Choose between:

**Choreography Saga:** Each service publishes events that trigger the next step. Map the happy path: [STEP 1] -> Event A -> [STEP 2] -> Event B -> [STEP 3] -> Event C -> [COMPLETION]. Then map every compensation path: if [STEP 3] fails, publish [COMPENSATION EVENT C] which triggers [STEP 2 ROLLBACK] which publishes [COMPENSATION EVENT B] which triggers [STEP 1 ROLLBACK]. Provide the complete event chain for [NUMBER: 4-6] steps with all failure scenarios.

**Orchestration Saga:** Use [ORCHESTRATOR: AWS Step Functions / Azure Durable Functions / GCP Workflows / Temporal] to coordinate the saga centrally. Design the state machine with these states: each task step with input/output mapping, error catchers with retry configuration (exponential backoff, max attempts, jitter), compensation branches triggered by specific error types, timeout handling for steps that depend on external callbacks, and a final state that emits either [SUCCESS_EVENT] or [FAILURE_EVENT] with full context.

Provide the complete state machine definition in [FORMAT: Amazon States Language / Azure Durable Functions code / YAML workflow definition] with inline comments explaining each decision.

### Error Handling & Dead Letter Queue Strategy

Design the multi-layer error handling strategy:

**Function-Level:** Implement structured error handling within each function. Categorize errors as transient (retry-safe: network timeouts, throttling, temporary service unavailability) versus permanent (do not retry: validation failures, missing required data, business rule violations). Configure retry policies per error type: [TRANSIENT: 3 retries with exponential backoff starting at 1s, max 30s] and [PERMANENT: immediate routing to DLQ with full context].

**Infrastructure-Level:** Configure [DLQ SERVICE: SQS DLQ / Azure Service Bus DLQ / Pub/Sub dead-letter topic] for each event consumer. Include the original event, error details, attempt count, timestamp of each retry, and function execution context. Build a DLQ processing pipeline: automated alerting when DLQ depth exceeds [THRESHOLD: 10 / 100 / custom], a replay mechanism that can reprocess DLQ messages after the root cause is fixed with [TOOL: custom Lambda / Step Functions / manual CLI], and a poison pill detector that identifies and quarantines events causing repeated failures across multiple consumers.

### Observability & Distributed Tracing

Implement comprehensive observability for the serverless event-driven system using [OBSERVABILITY STACK: AWS X-Ray + CloudWatch / Azure Application Insights / GCP Cloud Trace + Cloud Logging / OpenTelemetry + Jaeger + Grafana]:

**Distributed Tracing:** Propagate correlation IDs through all events and function invocations. Inject a trace context (W3C Trace Context or [CUSTOM HEADER]) into every event envelope and extract it in every consumer. This enables end-to-end trace visualization from initial trigger through all fan-out branches and saga steps.

**Metrics:** Define custom CloudWatch/Prometheus metrics for: event processing latency (p50, p95, p99) per event type, event throughput per consumer, DLQ depth and growth rate, saga completion rate and average duration, cold start frequency and duration per function, and concurrent execution count versus reserved concurrency.

**Alerting:** Configure alerts for: end-to-end latency exceeding [SLA: 1s / 5s / 30s / custom], DLQ receiving any messages (severity: warning) or exceeding threshold (severity: critical), saga failure rate exceeding [PERCENTAGE: 1% / 5%], function error rate exceeding [PERCENTAGE: 0.1% / 1%], and throttling events indicating capacity limits.