NOTE
Event-Driven Architecture
Producing and reacting to events with asynchronous coupling, delivery semantics, ordering, idempotency, and observability.
This is a historical learning note and may contain outdated or incomplete understanding.
Event-driven architecture connects components through events that describe something that happened. Producers do not need to synchronously call every consumer, which can reduce temporal coupling and improve independent scaling.
The trade-off is distributed state and asynchronous failure: delivery can duplicate, arrive late/out of order within the protocol’s guarantees, and consumers can fail after partial side effects.
Use stable event schemas, idempotent consumers, replay/dead-letter/repair paths, correlation/trace metadata, and explicit ownership. Do not call a command/request an “event” merely because it travels through a broker.