Event-Driven Architecture

Event-driven design trades tight coupling for asynchronous workflows—and introduces ordering, duplicates, schema evolution, and distributed tracing challenges.

When to Offer This Workflow

Trigger conditions:

• Replacing long chains of synchronous HTTP calls
• Adopting Kafka, Pub/Sub, EventBridge, NATS, etc.
• Need for sagas, compensating transactions, or cross-service workflows

Initial offer:

Use six stages: (1) identify events, (2) contracts & versioning, (3) delivery semantics, (4) orchestration vs choreography, (5) observability, (6) failure & replay). Assume at-least-once delivery unless proven otherwise.

Stage 1: Identify Events

Goal: Distinguish domain events (facts that happened) from commands (requests). Assign owning bounded context per event type.

Exit condition: Event catalog: name, schema, producers, consumers, SLAs.

Stage 2: Contracts & Versioning

Goal: Schema registry or equivalent; backward-compatible evolution; consumers ignore unknown fields; deprecation policy for old versions.

Stage 3: Delivery Semantics

Goal: Partition keys for per-entity ordering; idempotent consumers; dedupe keys when exactly-once illusion is needed.

Stage 4: Orchestration vs Choreography

Goal: Central orchestrator (saga coordinator) vs decentralized choreography—trade visibility vs coupling.

Practices

• Transactional outbox when DB write and event publish must align

Stage 5: Observability

Goal: Correlation ids on events; traces spanning HTTP → broker → consumer; lag and DLQ depth metrics.

Stage 6: Failure & Replay

Goal: Dead-letter queues, replay tooling, poison message handling, and idempotent replays.

Final Review Checklist

• [ ] Event inventory with clear ownership
• [ ] Versioned contracts and compatibility rules
• [ ] Idempotent consumers; partition strategy documented
• [ ] Saga/outbox where transactional consistency required
• [ ] Tracing and replay operationalized

Tips for Effective Guidance

• Choreography can hide flows—document critical sequences as diagrams.
• Pair with message-queues and idempotency for implementation detail.

Handling Deviations

• Low volume: start with a simple queue before full Kafka topology.