Event Driven Architecture

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

kimtth 556b3b2 1.1 KB Updated

File contents

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

kimtth/agent-skill-100-lines-or-less/tree/main/skills/event-driven-architecture commit 556b3b2774

Frequently asked questions

npx skillmds@latest add kimtth/event-driven-architecture