Event Driven

Workflows

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.

Install

openclaw skills install 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.