Event-Driven Architecture
also called EDA
A style in which components communicate by emitting and reacting to facts about what happened, rather than by calling each other.
The inversion that defines it: the producer does not know who consumes. It publishes "OrderPlaced" and stops caring. Adding a fifth consumer requires no change to the producer, which is the decoupling people are buying.
What it costs is the thing that is hardest to get back: end-to-end comprehensibility. No single place describes what happens when an order is placed; the flow is emergent from the subscriptions. Debugging requires correlation IDs and tracing that you must build. Testing requires either consumer-driven contracts or accepting that integration is verified in production.
Two design rules that separate durable event architectures from painful ones. Emit facts about the past ("OrderPlaced"), not commands in disguise ("SendEmail") — the second is an RPC with extra steps and recreates the coupling. And treat the event schema as a published contract with compatibility rules, because a consumer may read an event written months ago.