event-driven-architecturelisted

# Event-driven architecture Events invert control: producers announce what happened and forget; consumers react on their own schedule. This buys decoupling and scalability at the price of a system whose behavior lives in no single place, so the design discipline is making that distributed behavior traceable and its contracts stable. ## Method 1. **Model events as immutable business facts.** Past tense, named for what happened (`OrderPlaced`, not `OrderService.update`), carrying the identifiers and the facts consumers need, with a version and timestamp (see event-sourcing's event design; the same rule whether or not you store the log). Events are commands' opposite: they announce, they do not instruct, and they cannot be rejected. 2. **Choose choreography and orchestration deliberately.** Choreography (services react to events independently) scales and decouples but scatters the workflow: no one place answers "where is order 123" (see saga-pattern's same tradeoff). Orchestration (a coordinator drives the steps) keeps flows readable at the cost of a central component. Use choreography for genuinely independent reactions, orchestration for multi-step business processes: mixing them by accident is how event systems become unknowable. 3. **Treat event schemas as contracts.** Producers and consumers are coupled through the event shape; evolve it additively (new optional fields), version breaking changes, and enforce compat