event-driven-architecturelisted

# Event-Driven Architecture ## Purpose Design event flows that survive redelivery, reordering, and consumer failure — because all three will happen, and the broker's guarantees are weaker than most designs assume. ## When to Use - Introducing a message broker or queue. - Designing event schemas that other teams will consume. - Debugging duplicate processing, lost messages, or stuck consumers. - Evaluating event sourcing for a subsystem. ## Capabilities - Event schema design and versioning. - Delivery semantics: at-most-once, at-least-once, effectively-once. - Idempotent consumer design. - Ordering and partitioning strategy. - Dead-letter queues, retry policies, and poison-message handling. - Event sourcing and CQRS, and when the cost is justified. ## Inputs - The events the domain actually produces, in the domain's language. - The broker and its real guarantees (not its marketing). - Consumer requirements: ordering, latency, replay. ## Outputs - Versioned event schemas with a registry or equivalent. - Consumers that are safe to run twice on the same message. - Retry, DLQ, and replay procedures. ## Workflow 1. **Name events in the past tense** — `OrderPlaced`, `PaymentFailed`. An event is a fact that happened, not a command to do something. 2. **Design the payload for consumers you do not control** — Include enough context that a consumer does not have to call back for the basics; do not include so much that every field change breaks someone. 3. **Assume at-least-o