AWS Event-Driven Serverless Architecture — Overview
Event-driven architecture (EDA) decouples services by communicating through events rather than direct calls. Combined with serverless compute, it provides automatic scaling, zero idle cost, and fault-tolerant loose coupling. This is a core pattern for SAP-C02 (architectural decisions) and DOP-C02 (automation and failure handling).
(user actions)
(object events)
(data changes)
(device data)
(alarms)
(partner events)
Stateless
Auto-scales
Max 15 min
Load leveling
Retry with backoff
DLQ for failures
Multiple subscribers
Filter policies
Push-based
Multi-step workflows
Error handling
Wait states
High throughput
Multiple consumers
Replay window
Core Event-Driven Patterns
1. Point-to-Point (Queue)
One producer → One consumer. SQS decouples them with buffering and retry.
- Use case: Order processing, task queues, async job execution
- Pattern: API Gateway → SQS → Lambda (poll-based)
- Guarantee: At-least-once (Standard) or Exactly-once (FIFO)
2. Pub/Sub (Fan-out)
One event → Multiple consumers process independently.
- Use case: Order placed → update inventory + send email + update analytics
- Pattern: SNS topic → multiple SQS queues (each with own Lambda consumer)
- Variant: SNS + filter policies → each subscriber gets only relevant events
3. Event Bus (Content-Based Routing)
Central router matches events to rules and routes to appropriate targets.
- Use case: Multi-service system where different events go to different processors
- Pattern: EventBridge rules with content filtering → specific Lambda/SQS/Step Functions per event type
- Advantage: Producers don’t know about consumers — fully decoupled
4. Orchestration (Step Functions)
Central coordinator manages multi-step workflows with branching, error handling, and retries.
- Use case: Order fulfillment (validate → charge → ship → notify), ETL pipelines
- Pattern: Step Functions state machine calling Lambda, ECS, Bedrock, DynamoDB directly
- Advantage: Visual workflow, built-in retry/catch, wait states, parallel execution
5. Choreography (Distributed Events)
No central coordinator — each service reacts to events and emits new events.
- Use case: Loosely coupled microservices, event sourcing
- Pattern: Service A emits event → EventBridge → Service B reacts + emits new event → Service C reacts
- Trade-off: More autonomous but harder to debug/trace end-to-end
Service Comparison — When to Use Which
| Requirement | Service | Why |
|---|---|---|
| Buffer/decouple producer from consumer | SQS | Queue absorbs spikes, consumer processes at own pace |
| One event → multiple consumers | SNS (or SNS+SQS) | Fan-out to multiple subscribers with filtering |
| Route events from many sources by content | EventBridge | Content-based rules, schema discovery, archive/replay |
| Multi-step workflow with error handling | Step Functions | Visual orchestration, retry/catch, parallel, wait states |
| High-throughput ordered streaming | Kinesis Data Streams | Shard-based ordering, multiple consumers, replay |
| Exactly-once with strict ordering | SQS FIFO | Message groups guarantee order + deduplication |
| Cross-account/cross-region events | EventBridge | Native cross-account event buses, global endpoints |
Error Handling & Resilience
| Mechanism | Service | How It Works |
|---|---|---|
| Dead Letter Queue (DLQ) | SQS, SNS, Lambda, EventBridge | Messages that fail max retries are sent to DLQ for investigation |
| Lambda Destinations | Lambda | Route success/failure results to SQS, SNS, EventBridge, or another Lambda |
| Retry with backoff | SQS (visibility timeout), Step Functions (Retry) | Exponential backoff prevents thundering herd on transient failures |
| Step Functions Catch | Step Functions | Catch errors per state → route to fallback/compensation logic |
| EventBridge Archive & Replay | EventBridge | Archive all events → replay specific time ranges after fixing consumer bugs |
Idempotency — Critical for Event-Driven
At-least-once delivery means consumers may process the same event multiple times. Design for idempotency:
- DynamoDB conditional writes — Use event ID as key, conditional put (only if not exists)
- SQS FIFO deduplication — Built-in 5-minute deduplication window
- Idempotency key in Lambda — Store processed event IDs in DynamoDB/ElastiCache, skip if seen
- Powertools for Lambda — AWS Lambda Powertools provides idempotency utility out of the box
Scaling Considerations
- Lambda concurrency: Default 1000/region. Use reserved concurrency for critical functions, SQS batching to control invocation rate.
- SQS → Lambda scaling: Lambda auto-scales up to 1000 concurrent by adding 60 instances/minute. Batch size (1-10K) controls throughput.
- EventBridge throttling: 2400 PutEvents/sec default (soft limit). Rules trigger targets with target-specific throttling.
- Step Functions: Standard (2000 state transitions/sec), Express (100K/sec) — choose based on volume.
- SNS: Virtually unlimited throughput for publishing. Subscriber delivery follows target limits.
Exam Tips by Certification
| Exam | Focus Areas |
|---|---|
| SAP-C02 | Decoupling patterns (SQS vs SNS vs EventBridge selection), ordering guarantees (FIFO vs Standard), fan-out architectures, saga pattern for distributed transactions, cross-account event routing |
| DOP-C02 | DLQ monitoring and alerting, Lambda failure handling (destinations vs DLQ), Step Functions error/retry configuration, EventBridge replay for recovery, observability with X-Ray tracing across async services |
AWS Certification Exam Practice Questions
Question 1:
An e-commerce application needs to process an order event by simultaneously updating inventory, sending a confirmation email, and notifying the warehouse. Each downstream service should process independently and failures in one should NOT affect others. Which pattern is MOST appropriate?
- SQS queue with a single Lambda consuming and calling each service
- SNS topic with SQS queue subscriptions for each downstream service (each with own Lambda)
- Step Functions parallel state calling all three services
- EventBridge with a single rule targeting all three Lambdas
Show Answer
Answer: B – SNS→SQS fan-out provides independent processing per consumer. Each SQS queue has its own Lambda, retry policy, and DLQ. If the email service fails, inventory and warehouse continue unaffected. A single Lambda calling all three creates coupling. Step Functions parallel would work but adds cost/complexity for simple fan-out. EventBridge directly to Lambda doesn’t provide the buffering/retry isolation of SQS.
Question 2:
A financial system processes payment events that MUST be processed exactly once and in the order they were submitted per customer. Different customers’ payments can be processed in parallel. Which configuration provides this?
- SQS Standard queue with Lambda deduplication logic
- SQS FIFO queue with MessageGroupId set to customer ID
- Kinesis Data Stream with partition key set to customer ID
- EventBridge with ordered delivery enabled
Show Answer
Answer: B – SQS FIFO with MessageGroupId provides exactly-once processing AND strict ordering within each message group (customer). Different message groups (different customers) process in parallel. Kinesis provides ordering per shard partition key but only at-least-once delivery (not exactly-once). Standard SQS doesn’t guarantee ordering.
Question 3:
A multi-step order fulfillment process (validate → charge → reserve inventory → ship → notify) needs to compensate previous steps if a later step fails (e.g., refund if shipping fails). Which approach implements this saga pattern?
- Lambda function chaining (each Lambda invokes the next)
- Step Functions with Catch blocks that invoke compensation Lambdas
- SQS with manual retry and DLQ
- EventBridge choreography with each service emitting success/failure events
Show Answer
Answer: B – Step Functions orchestrated saga pattern defines the happy path and compensation logic. Each step has a Catch block that routes to compensation states (refund, release inventory). The state machine manages the entire transaction lifecycle with built-in retry, timeout, and error handling. Choreography can implement sagas but is harder to manage and debug.
Question 4:
A Lambda function consuming from SQS occasionally fails on certain messages (malformed data). These messages are retried repeatedly, consuming concurrency and blocking other messages. How should this be resolved?
- Increase Lambda timeout to give more processing time
- Configure maxReceiveCount on the SQS queue with a DLQ — messages exceeding retry limit move to DLQ for investigation
- Delete the malformed message in a try/catch block
- Increase SQS visibility timeout to delay retries
Show Answer
Answer: B – Setting maxReceiveCount (redrive policy) moves poison messages to a DLQ after N failed attempts. This prevents them from blocking the queue indefinitely while preserving them for debugging. Deleting silently loses the message. Longer timeouts just delay the same failure. The DLQ pattern is the standard for handling poison messages.
Question 5:
A company uses EventBridge to route events from 20+ microservices. A bug in a consumer caused it to discard events for 3 hours before being discovered. They need to reprocess those lost events. Which EventBridge feature enables this?
- EventBridge Pipes with enrichment
- EventBridge Archive and Replay
- EventBridge Schema Registry
- CloudWatch Logs Insights query on EventBridge logs
Show Answer
Answer: B – EventBridge Archive stores all events (or filtered events) indefinitely. Replay allows you to re-send archived events from a specific time window to the same or different event bus. This enables recovery from consumer bugs by replaying the 3-hour window after the consumer is fixed. No data is lost as long as archiving was enabled.
Related Posts
- AWS SQS Standard vs FIFO Queue
- AWS Kinesis Streams vs Firehose vs Managed Flink
- AWS Lambda Durable Functions
- AWS Lambda vs Step Functions vs EventBridge
- GenAI Application Architecture on AWS
- AWS Disaster Recovery Architecture
References
- AWS Event-Driven Architecture Overview
- Building an Event-Driven Application with Amazon EventBridge — AWS Compute Blog
- Let’s Architect: Designing Event-Driven Architectures — AWS Architecture Blog
- Event-Driven Architecture Pattern — AWS Prescriptive Guidance
- Implementing the Saga Pattern with AWS Step Functions — AWS Blog
Frequently Asked Questions
When should I use EventBridge vs SNS for fan-out?
Use SNS for simple fan-out where all subscribers get the same event (or basic attribute filtering). Use EventBridge when you need content-based filtering on any field in the event body, schema discovery, archive/replay, cross-account routing, or SaaS integration. EventBridge is more powerful; SNS is simpler and cheaper for basic pub/sub.
Should I use Step Functions or choreography (distributed events)?
Use Step Functions (orchestration) when you need clear visibility into workflow state, error handling with compensation (saga), and centralized control. Use choreography when services are independently developed/deployed by different teams and you want maximum autonomy. Orchestration is easier to debug; choreography scales organizational independence.
How do I handle poison messages in event-driven systems?
Configure a Dead Letter Queue (DLQ) with maxReceiveCount on SQS queues. After N failed processing attempts, the message moves to the DLQ. Set CloudWatch alarms on DLQ message count. Investigate and replay from DLQ after fixing the issue. For EventBridge, use Archive+Replay for recovery.