Event-Driven Architecture
Services communicate by emitting and reacting to events. Decoupled, resilient, and naturally scalable.
Overview
In event-driven architecture, services don't call each other directly — they produce events and consume events. Producers don't know who's listening. Consumers don't know who produced. This decoupling makes systems resilient and independently scalable.
Core Patterns
Pub/Sub
Producer publishes to a topic. All subscribers receive a copy. Fan-out at scale.
- SNS → multiple SQS queues
- EventBridge → multiple targets
Event Streaming
Ordered, replayable event log. Consumers read at their own pace. Data retained for days/weeks.
- Kinesis Data Streams
- MSK (Kafka)
Queue-Based
Point-to-point delivery with buffering. Decouples producers from consumers temporally.
- SQS Standard (at-least-once)
- SQS FIFO (exactly-once, ordered)
Event Sourcing
Store state as a log of events, not current state. Replay to reconstruct any point in time.
- DynamoDB Streams
- Kinesis + S3 archive
Resilience Patterns
- Dead Letter Queue (DLQ) — failed messages land here for inspection and replay
- Retry with backoff — exponential backoff on transient failures
- Idempotency — design consumers to handle duplicate delivery safely
- Schema registry — AWS Glue Schema Registry enforces event contracts
References
EventBridge Integration Patterns
Real-world EventBridge patterns with rules, targets, and error handling
GitHubTerraform SQS Module
SQS queue setup with DLQ, encryption, and access policies
GitHubEvent-Driven Architectures on AWS
AWS whitepaper covering patterns, anti-patterns, and service selection
AWS Whitepaper