Architecture
A serverless event processing architecture diagram with S3, DynamoDB Streams, API Gateway, and CloudWatch triggers invoking Lambda functions, orchestrated by Step Functions with fan-out via SQS and dead letter queue error handling. This template shows how to build complex event processing pipelines entirely from managed serverless components, with no servers to provision or manage. Ideal for data processing workflows that need elastic scaling and built-in fault tolerance.
Full FlowZap Code
EventSources { # Event Sources
n1: rectangle label:"S3 Bucket Upload"
n2: rectangle label:"DynamoDB Stream"
n3: rectangle label:"API Gateway Webhook"
n4: rectangle label:"CloudWatch Scheduled Rule"
n1.handle(bottom) -> Triggers.n5.handle(top) [label="ObjectCreated"]
n2.handle(bottom) -> Triggers.n6.handle(top) [label="StreamRecord"]
n3.handle(bottom) -> Triggers.n7.handle(top) [label="POST Event"]
n4.handle(bottom) -> Triggers.n8.handle(top) [label="Cron"]
}
Triggers { # Lambda Triggers
n5: rectangle label:"Image Processing Lambda"
n6: rectangle label:"Data Sync Lambda"
n7: rectangle label:"Webhook Handler Lambda"
n8: rectangle label:"Batch Job Lambda"
n5.handle(bottom) -> Processing.n9.handle(top) [label="Process Image"]
n6.handle(bottom) -> Processing.n11.handle(top) [label="Sync Data"]
n7.handle(bottom) -> Processing.n9.handle(top) [label="Handle Event"]
n8.handle(bottom) -> Processing.n12.handle(top) [label="Run Batch"]
}
Processing { # Processing Pipeline
n9: rectangle label:"Step Functions Orchestrator"
n10: diamond label:"Processing Complete?"
n11: rectangle label:"Transform and Load"
n12: rectangle label:"Fan-Out with SQS"
n13: rectangle label:"Error Handler Lambda"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left) [label="Success"]
n10.handle(bottom) -> n13.handle(top) [label="Failure"]
n12.handle(right) -> n11.handle(left) [label="Parallel"]
n13.handle(bottom) -> Storage.n17.handle(top) [label="DLQ"]
n11.handle(bottom) -> Storage.n14.handle(top) [label="Store"]
}
Storage { # Managed Storage
n14: rectangle label:"DynamoDB Table"
n15: rectangle label:"S3 Results Bucket"
n16: rectangle label:"SNS Notification Topic"
n17: rectangle label:"SQS Dead Letter Queue"
n14.handle(right) -> n15.handle(left) [label="Archive"]
n15.handle(right) -> n16.handle(left) [label="Notify"]
}
Why This Workflow?
Building event processing pipelines on traditional servers requires provisioning for peak load, managing scaling policies, and handling server failures. Serverless event processing automatically scales per-event, handles failures with built-in DLQ support, and costs nothing when idle—perfect for bursty, unpredictable workloads.
How It Works
- Step 1: Events from S3 uploads, DynamoDB streams, API webhooks, and scheduled rules trigger Lambda functions.
- Step 2: Each trigger type invokes a specialized Lambda function for its processing logic.
- Step 3: Step Functions orchestrate multi-step processing with branching and parallel execution.
- Step 4: SQS provides fan-out for parallel processing of independent work items.
- Step 5: Failed events are captured in a dead letter queue for investigation.
- Step 6: Processed results are stored in DynamoDB and S3, with SNS notifications for downstream consumers.
Alternatives
Container-based event processors (ECS) offer more control over runtime but require capacity management. Managed services like AWS EventBridge simplify routing. This template shows the fully serverless event processing pipeline.
Key Facts
| Template Name | Serverless Event Processing Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A serverless API backend architecture diagram with API Gateway, Lambda authorizer functions, business logic functions, and managed cloud services including DynamoDB, S3, SQS, and SNS for a fully managed, auto-scaling backend. This template models the serverless-first approach where infrastructure management is eliminated entirely, with pay-per-invocation pricing and automatic scaling to zero. Essential for startups and teams building cost-efficient, event-driven API backends.
Architecture
An AWS Step Functions orchestration architecture diagram with state machine workflows including choice states, parallel processing, wait-for-callback patterns, and compensation rollback for failed steps. This template models serverless workflow orchestration where complex multi-step processes are defined as state machines with built-in error handling and retry logic. Critical for teams building reliable serverless workflows that require human approval or long-running processes.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.