architecture-event-drivenlisted

# Architecture Event Driven ## Overview Use this skill to design event-driven systems that remain correct under retries, delays, and partial failures. ## Scope Boundaries - Workflows span multiple bounded contexts or services asynchronously. - Temporal decoupling is needed to improve autonomy or resilience. - Integration churn is high and direct RPC coupling causes fragility. ## Core Judgments - Event semantics: fact versus command and ownership of meaning. - Delivery guarantees: at-most-once, at-least-once, effectively-once patterns. - Ordering strategy: global ordering, per-key ordering, or order independence. - Recovery model: replay, dead-letter, compensating actions, and backfill. ## Practitioner Heuristics - Publish events as immutable domain facts from the source of truth. - Never rely on "exactly-once" assumptions; design idempotent consumers. - Partition keys must align with business consistency boundaries. - Version event contracts with additive evolution first; reserve breaking changes for controlled migrations. ## Workflow 1. Define domain events and ownership boundaries. 2. Specify producer guarantees and consumer idempotency requirements. 3. Choose ordering and partitioning strategies by business invariant. 4. Design failure-handling paths for retry storms, poison messages, and replay. 5. Align observability with event lifecycle (published, consumed, failed, compensated). 6. Document contract evolution and deprecation strategy. ## Common Failure Modes - Ev