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.