Event-Driven Architecture
In event-driven architecture, one component publishes a fact after something changes. Other components react later under clear rules for delivery and future format changes.
Another example
When subscription 42 is canceled, Billing publishes a versioned `SubscriptionCanceled` event with subject, time, and trace ID. Access and Analytics services react on their own and both remove duplicate event IDs. Analytics can replay the log later. A failed next step uses compensation instead of treating the whole flow as one transaction.
Main parts
- 01Event fact and schema
- 02Broker or event log
- 03Independent reacting consumers
Use it when
Use events for lasting facts needed by several independent consumers. Define who owns the schema, ordering, replay, and failure rules.
Do not use it when
Do not use events to hide a request chain whose parts must act together. Do not disguise a vague command as a past-tense fact.
Name used in code
versioned event envelope + durable broker/log + idempotent consumers + trace context Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Event-Driven Architecture for this system while keeping data correct, secure, and easy to operate. User context: When subscription 42 is canceled, Billing publishes a versioned `SubscriptionCanceled` event with subject, time, and trace ID. Access and Analytics services react on their own and both remove duplicate event IDs. Analytics can replay the log later. A failed next step uses compensation instead of treating the whole flow as one transaction. Technical concept or control: Event-Driven Architecture. Why it fits: Use events for lasting facts needed by several independent consumers. Define who owns the schema, ordering, replay, and failure rules. Do not use it when: Do not use events to hide a request chain whose parts must act together. Do not disguise a vague command as a past-tense fact. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Event-Driven Architecture. Definition: In event-driven architecture, one component publishes a fact after something changes. Other components react later under clear rules for delivery and future format changes. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.