Event Driven

Deep event-driven architecture workflow—events vs commands, ordering and idempotency, sagas, outbox pattern, observability, and failure modes. Use when designing async systems, event buses, or refactoring synchronous chains.

mike47512@mike47512

Install

openclaw skills install @mike47512/event-driven

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.