Designing Event-Driven Architecture
1. Understanding Event-Driven Architecture Patterns
| Pattern | Description |
|---|---|
| Event Notification | Lightweight signal; consumer fetches details |
| Event-Carried State Transfer | Event includes full payload |
| Event Sourcing | Events are source of truth |
| CQRS | Commands write events; queries read projections |
2. Designing Event Producers and Consumers
| Side | Concern |
|---|---|
| Producer | Atomicity (outbox), idempotent send, schema |
| Consumer | Idempotent processing, offset commit after success |
| Group | Partition assignment, rebalance handling |
| Backpressure | Pause consumer if downstream slow |
3. Designing Event Schema Design
| Field | Purpose |
|---|---|
| event_id | Unique (UUID); for dedup |
| event_type | OrderPlaced, OrderShipped |
| event_version | Schema version |
| occurred_at | ISO timestamp |
| aggregate_id | Entity id |
| data | Payload |
| metadata | Trace, user, tenant |
4. Designing Event Schema Registry
| Tool | Notes |
|---|---|
| Confluent Schema Registry | Avro/JSON/Protobuf compatibility |
| AWS Glue Schema Registry | Native AWS |
| Compatibility modes | BACKWARD, FORWARD, FULL, NONE |
| Subject naming | topic-value, topic-key |
5. Designing Event Versioning Strategy
| Strategy | Detail |
|---|---|
| Additive | Add optional fields; safe |
| Upcasting | Transform old → new on read |
| Multiple types | OrderPlacedV1, OrderPlacedV2 |
| Topic-per-version | orders.v1, orders.v2 |
6. Designing Event Sourcing Pattern
| Element | Detail |
|---|---|
| Event store | Append-only (EventStoreDB, Kafka, DB table) |
| Aggregate | Rehydrated by replay |
| Snapshot | Cache current state every N events |
| Projections | Read models built from events |
| Pros | Audit, replay, time travel |
| Cons | Schema migration, eventual consistency |
7. Designing Event Replay Capability
| Use Case | Detail |
|---|---|
| New projection | Replay all events into new read model |
| Bug fix backfill | Reprocess from offset 0 |
| A/B logic | Replay into shadow consumer |
| Tools | Kafka offset reset, Kinesis replay |
8. Designing Event Ordering Guarantees
| Scope | Detail |
|---|---|
| Per partition | Kafka guarantees order |
| Per key | Partition by aggregate_id |
| Global | Single partition (low throughput) |
| Reordering safe | Use sequence number / version |
9. Designing Event Deduplication
| Strategy | Detail |
|---|---|
| Idempotent producer | Kafka enable.idempotence=true |
| Inbox pattern | Consumer DB stores processed event_id |
| TTL bloom filter | Memory-efficient dedup window |
| Broker-side | Pulsar deduplication |
10. Designing Event-Carried State Transfer
| Pro | Con |
|---|---|
| Consumer self-sufficient (no callback) | Larger events |
| Resilient to producer outage | Stale data if consumer slow |
| Easy to materialize read model | PII/sensitive data spread |
11. Designing Choreography vs Orchestration
| Aspect | Choreography | Orchestration |
|---|---|---|
| Control | Distributed; services react | Central orchestrator |
| Coupling | Loose | Coupled to orchestrator |
| Observability | Hard (multi-hop) | Easy (one place) |
| Best for | Simple flows, evolving | Complex / regulated workflows |
| Tools | Kafka events | Temporal, Camunda, Step Functions |
12. Designing Event Store Architecture
| Implementation | Detail |
|---|---|
| Append-only table | (stream_id, version, type, data, metadata, ts) |
| Optimistic concurrency | Append fails if version mismatch |
| Subscription | Tail $all stream; push to consumers |
| Snapshots | Separate table; load latest + tail |
| Tools | EventStoreDB, Marten, Axon, Kafka |