# Event Driven Architecture

> Use when: design systems around events and messages with reliable, decoupled processing.

- Skill: `kimtth/event-driven-architecture` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kimtth/event-driven-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kimtth/event-driven-architecture/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kimtth (https://skillmd.com/u/kimtth)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kimtth/event-driven-architecture

---


Goal: decoupled components that react to events reliably.

Use for:
- decoupling producers from consumers
- async workflows, integrations, and fan-out
- designing topics, queues, and event schemas

Workflow:
1. Define events as facts about what happened, named in past tense.
2. Version event schemas; keep them backward compatible.
3. Choose delivery semantics: at-least-once is the common default.
4. Make consumers idempotent to tolerate redelivery.
5. Handle failures with retries and a dead-letter queue.
6. Verify ordering and replay behavior under load.

Patterns:
- publish/subscribe for fan-out
- outbox pattern for atomic write-and-publish
- idempotency keys to dedupe processing
- dead-letter queues for poison messages

Rules:
- assume at-least-once delivery; design idempotent consumers
- events are immutable facts, not commands
- evolve schemas additively; never break consumers
- never lose a failed message silently; dead-letter it