Event-Driven Architecture

EVENT TYPES:

DOMAIN EVENTS (Business Events)
├── OrderPlaced, PaymentReceived, UserRegistered
├── Represent business-meaningful occurrences
├── Consumed by business logic
└── Example: {"event": "OrderPlaced", "orderId": "123", "amount": 99.99}

SYSTEM EVENTS (Infrastructure Events)
├── EC2 state changes, S3 object created, CloudWatch alarms
├── Emitted by AWS services automatically
├── Consumed for automation and monitoring
└── Example: {"source": "aws.ec2", "detail-type": "EC2 Instance State-change"}

INTEGRATION EVENTS (Cross-Service)
├── Events shared between microservices
├── Define service boundaries
├── Enable loose coupling
└── Example: {"source": "inventory-service", "detail-type": "StockUpdated"}

STANDARD QUEUE:
├── Nearly unlimited throughput
├── At-least-once delivery (may have duplicates)
├── Best-effort ordering (may be out of order)
├── Use for: High throughput, duplicate-tolerant workloads
└── Price: Lower cost

FIFO QUEUE:
├── 300 TPS (3,000 with batching)
├── Exactly-once processing
├── Strict ordering within message groups
├── Use for: Order-sensitive processing, financial transactions
└── Price: Higher cost, requires .fifo suffix

KEY FEATURES:
├── Visibility Timeout: Prevents other consumers from processing
├── Dead Letter Queue (DLQ): Captures failed messages
├── Long Polling: Reduces empty responses, saves cost
├── Delay Queues: Postpone message delivery
└── Message Retention: 1 minute to 14 days

SNS TOPIC TYPES:

STANDARD TOPIC:
├── High throughput
├── At-least-once delivery
├── Best-effort ordering
└── Use for: Notifications, fan-out

FIFO TOPIC:
├── Strict ordering
├── Exactly-once delivery
├── Works with SQS FIFO queues
└── Use for: Ordered processing pipelines

SUBSCRIBER TYPES:
├── Lambda functions
├── SQS queues
├── HTTP/HTTPS endpoints
├── Email/SMS
├── Mobile push
├── Kinesis Data Firehose
└── Other AWS accounts

MESSAGE FILTERING:
├── Filter by message attributes
├── Subscribers only receive matching messages
├── Reduces processing overhead
└── JSON filter policy on subscription

EVENTBRIDGE ARCHITECTURE:

EVENT BUS:
├── Default Bus: Receives AWS service events
├── Custom Bus: For your application events
├── Partner Bus: Third-party SaaS events
└── Cross-account buses supported

RULES:
├── Match events using patterns
├── Route to one or more targets
├── Transform events before delivery
├── Up to 300 rules per bus
└── 5 targets per rule

EVENT PATTERN (Example):
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped", "terminated"]
  }
}

TARGETS:
├── Lambda, Step Functions
├── SQS, SNS, Kinesis
├── ECS tasks, CodePipeline
├── API Gateway, API destinations
├── Other event buses
└── 20+ supported targets

FAN-OUT PATTERN:

                    ┌─── SQS Queue 1 ─── Lambda (Analytics)
                    │
SNS Topic ──────────┼─── SQS Queue 2 ─── Lambda (Notification)
                    │
                    └─── SQS Queue 3 ─── Lambda (Archival)

USE CASES:
├── Process same event for multiple purposes
├── Different processing speeds per consumer
├── Fault isolation (one queue failure doesn't affect others)
├── Different scaling requirements
└── A/B testing with parallel paths

BENEFITS:
├── Decoupled consumers
├── Independent scaling
├── Fault isolation
├── Message durability (SQS retention)
└── Asynchronous processing

EVENT SOURCING ARCHITECTURE:

WRITE PATH:
Command → Validate → Store Event → Publish Event
         │                │              │
         │                ▼              ▼
         │          DynamoDB        EventBridge
         │         (Event Store)         │
         │                               ▼
         └─────────────────────── Update Read Model

EVENT STORE (DynamoDB):
┌──────────────────────────────────────────────────────┐
│ PK: order-123   SK: event-001   Data: OrderCreated   │
│ PK: order-123   SK: event-002   Data: ItemAdded      │
│ PK: order-123   SK: event-003   Data: PaymentReceived│
│ PK: order-123   SK: event-004   Data: OrderShipped   │
└──────────────────────────────────────────────────────┘

BENEFITS:
├── Complete audit trail
├── Temporal queries (state at any time)
├── Event replay for debugging
├── Supports CQRS pattern
└── Natural fit for event-driven systems

CHALLENGES:
├── Eventual consistency
├── Event schema evolution
├── Storage growth over time
└── Complexity in querying

CQRS ARCHITECTURE:

         COMMANDS                        QUERIES
            │                               │
            ▼                               ▼
      ┌──────────┐                   ┌──────────┐
      │ API GW   │                   │ API GW   │
      │ (Write)  │                   │ (Read)   │
      └────┬─────┘                   └────┬─────┘
           │                               │
           ▼                               ▼
      ┌──────────┐                   ┌──────────┐
      │ Lambda   │                   │ Lambda   │
      │ (Command)│                   │ (Query)  │
      └────┬─────┘                   └────┬─────┘
           │                               │
           ▼                               ▼
      ┌──────────┐    Events        ┌──────────┐
      │ DynamoDB │ ──────────────►  │ Aurora   │
      │ (Write)  │   EventBridge    │ (Read)   │
      └──────────┘                  └──────────┘

WHEN TO USE CQRS:
├── Read and write loads differ significantly
├── Complex domain with different read/write models
├── Need to scale reads and writes independently
├── Acceptable eventual consistency for reads
└── Different teams work on read vs write

WHEN NOT TO USE:
├── Simple CRUD applications
├── Strong consistency required everywhere
├── Small scale, low complexity
└── Single team, rapid iteration

STRATEGIES FOR EVENTUAL CONSISTENCY:

1. OPTIMISTIC UI
   ├── Update UI immediately (assume success)
   ├── Reconcile when event confirms
   └── Handle conflicts gracefully

2. IDEMPOTENT CONSUMERS
   ├── Processing same event twice has same result
   ├── Use event ID for deduplication
   └── Critical for at-least-once delivery

3. VERSION TRACKING
   ├── Include version in events and state
   ├── Reject stale updates
   └── Implement optimistic locking

4. COMPENSATION EVENTS
   ├── When things go wrong, emit compensating event
   ├── OrderCancelled reverses OrderPlaced
   └── Saga pattern for distributed transactions

5. READ-YOUR-WRITES
   ├── Route user's reads to same replica they wrote to
   ├── Or cache recent writes client-side
   └── Provides consistency illusion

DLQ ARCHITECTURE:

Source Queue ──► Consumer ──► Success
                   │
                   ├── Retry 1 ──► Fail
                   ├── Retry 2 ──► Fail
                   ├── Retry 3 ──► Fail
                   │
                   ▼
              Dead Letter Queue ──► Analysis/Reprocessing

SQS DLQ CONFIGURATION:
{
  "RedrivePolicy": {
    "deadLetterTargetArn": "arn:aws:sqs:region:account:my-dlq",
    "maxReceiveCount": 3
  }
}

LAMBDA EVENT SOURCE DLQ:
├── Configure on Lambda event source mapping
├── Failed events after retries go to DLQ
├── Works with SQS, Kinesis, DynamoDB Streams
└── Preserves event for reprocessing

EVENTBRIDGE DLQ:
├── Configure on rule target
├── Captures events that fail delivery
├── Includes error information
└── Enables retry and analysis

BEST PRACTICES:
├── Always configure DLQs for production
├── Set up CloudWatch alarms on DLQ depth
├── Include correlation IDs for tracing
├── Implement automated reprocessing where safe
└── Manual review for unknown failures

USE SQS WHEN:
├── Need message buffering/retention
├── Want to control processing rate
├── Need exactly-once with FIFO
├── Decoupling producer from consumer speed
├── Work distribution to multiple workers
└── Handling traffic spikes gracefully

USE SNS WHEN:
├── Need fan-out to multiple consumers
├── Push-based delivery required
├── Sending notifications (email, SMS, mobile)
├── Simple pub/sub without complex routing
└── A2A (application-to-application) messaging

USE EVENTBRIDGE WHEN:
├── Need content-based event routing
├── Integrating with AWS service events
├── Building event-driven microservices
├── Want event transformation/enrichment
├── Cross-account or cross-region events
├── SaaS integration (partner events)
└── Default choice for new architectures

// Match EC2 instance state changes
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["running", "stopped"]
  }
}

// Match S3 object creation in specific bucket
{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": {
      "name": ["my-bucket"]
    }
  }
}

// Match custom application events with prefix
{
  "source": ["myapp.orders"],
  "detail-type": ["Order Placed"],
  "detail": {
    "amount": [{"numeric": [">=", 100]}],
    "region": [{"prefix": "us-"}]
  }
}