Why Patterns Emerge
Why Patterns Emerge
Serverless removes servers but concentrates design pressure onto messaging and state. Each classic pattern answers one structural failure:
- Fan-out — one event must reach many independent consumers without the producer knowing them.
- Saga — a transaction spans services, so failure needs explicit compensation instead of a distributed rollback.
- CQRS — read and write workloads have different shapes (high-write ledger vs fast search), so separate the models.
- Event sourcing — you need a full audit trail or rebuilds, so the append-only event log is the source of truth rather than the current row.
On AWS these map to SNS/SQS, Step Functions, separate stores, and DynamoDB or S3 logs.
Implementing the Patterns
Implementing the Patterns
Fan-out: S3/SNS event ─▶ SQS queue A ─▶ Lambda (email)
└──▶ SQS queue B ─▶ Lambda (index)
Saga: Step Functions: reserve → charge → ship
└─ failure: release, refund (compensations)
CQRS: API Gateway ─▶ DynamoDB (writes)
DynamoDB Streams ─▶ Lambda ─▶ OpenSearch (read model)
Sourcing: append events to DynamoDB/S3, rebuild
projections by replaying the log
Each consumer gets its own queue so a slow or failing pipeline cannot block the others; DLQs isolate poison messages. Step Functions keeps saga state and retries without you coding a workflow engine.
Pitfalls and Interview Focus
Pitfalls and Interview Focus
AWS delivery is at-least-once everywhere: Lambda may run twice and SNS/SQS can duplicate. Every consumer must be idempotent — dedupe on an event ID or use conditional writes. Ordering requires FIFO topics/queues, which trade throughput for sequence; standard queues give none.
Other traps: sagas without tested compensations (you wrote the happy path only); read models minutes stale, surprising users who just wrote; projections assuming events never change shape — version your event schema; and chatty fan-outs where one API call should emit a single event.
Interview: describe a pattern as event flow plus failure behavior — who retries, where duplicates die, and what the user sees during partial failure.
Quiz
1. Which pattern fits "an order event must update inventory, send email, and index search"?
2. Why must Lambda consumers be idempotent?
3. In CQRS, where do read-model updates typically come from?
Flashcards
Question
Fan-out
Click to reveal answer
Answer
One event, many consumers — SNS/SQS with a dedicated queue per consumer plus DLQs.
Question
Saga
Click to reveal answer
Answer
Compensating transactions replace rollback when one action spans services (Step Functions).
Question
CQRS
Click to reveal answer
Answer
Separate models for reads and writes, synced asynchronously via streams.
Question
Event sourcing
Click to reveal answer
Answer
Append-only event log is the source of truth; state = fold(events).
Question
Idempotency key
Click to reveal answer
Answer
Stable event ID used to dedupe duplicate deliveries in at-least-once systems.
Revision Notes
Key Takeaways
- 1. Pick the pattern from the failure shape: many consumers, multi-step rollback, split workloads, audit log
- 2. Assume duplicates and reordering unless you pay for FIFO
- 3. Version event schemas and test compensations, not just happy paths
Interview Tips
- • Answer pattern questions as event flow + failure behavior (retries, duplicates, partial visibility)
- • Say where ordering and deduplication live in your design before moving on
Cheat Sheet
Fan-out=SNS/SQS per consumer; Saga=Step Functions compensations; CQRS=Streams→read store; Sourcing=append-only log + projections. At-least-once: idempotent consumers, DLQs; FIFO for order.
Continue Learning
Before You Start
- No prerequisites listed.