3.3.1.2. Event-Driven Architectures (Fan Out, Event Streaming, Queuing)
3.3.1.2. Event-Driven Architectures (Fan Out, Event Streaming, Queuing)
Event-driven patterns decouple event producers from consumers, enabling independent scaling and failure isolation.
Fan-out pattern (SNS): One event triggers multiple parallel consumers. An order event fans out to inventory, billing, shipping, and analytics simultaneously.
Order Created → SNS Topic → SQS (Inventory)
→ SQS (Billing)
→ Lambda (Analytics)
→ Kinesis (Event Store)
Queuing pattern (SQS): Producer → Queue → Consumer. Queue buffers during traffic spikes and ensures messages survive consumer failures.
- Standard queue: At-least-once delivery, best-effort ordering, unlimited throughput
- FIFO queue: Exactly-once processing, strict ordering, 3,000 msg/s with batching
Event streaming (Kinesis): Continuous, ordered stream of events processed in real-time. Unlike SQS (each message consumed once), Kinesis allows multiple consumers to read the same stream independently.
- Kinesis Data Streams: Custom processing with Lambda, EC2, or KCL consumers
- Kinesis Data Firehose: Managed delivery to S3, OpenSearch, Redshift, Splunk
When to use each:
| Pattern | Service | Best For |
|---|---|---|
| Point-to-point | SQS | Decoupled microservices, work queues |
| Fan-out | SNS + SQS | One event, multiple consumers |
| Streaming | Kinesis | Real-time analytics, ordered event processing |
| Complex routing | EventBridge | Content-based routing, cross-account events |
Exam Trap: SQS messages become invisible during processing (visibility timeout). If the consumer crashes before deleting the message, it reappears after the visibility timeout and gets reprocessed. If the consumer is too slow, the message reappears while still being processed, causing duplicates. Set visibility timeout to at least 6x your average processing time.
