Event-Driven Architecture
also: EDA
An architecture where components communicate by emitting and reacting to events, rather than calling each other directly.
Event-driven architecture structures a system around events — notifications that something happened (“payment received”) — which components emit and react to asynchronously, instead of calling each other with direct requests. It decouples producers from consumers and enables loose, scalable coupling.
Worked example: instead of the checkout service directly calling email, inventory, and shipping (and waiting on each), it emits one “order.placed” event; those services react on their own schedule, so checkout stays fast and a downstream failure does not block it. Gotcha: event-driven systems trade request/response simplicity for eventual consistency and harder debugging — there is no single call stack to trace, ordering and duplicates must be handled, and “what is the current state?” becomes a question of replaying events — which is why observability (tracing, event logs) is essential.