What is Event-driven architecture?

Event-driven architecture (EDA) is a design style in which the flow of a system is determined by events: immutable records that something meaningful occurred (an order was placed, a user signed up, a payment failed). Instead of one service synchronously calling another and waiting, services emit events to a broker, and other services react to the events they care about, on their own schedule, without the emitter knowing they exist. This inversion produces loose coupling: you can add a new consumer (say, a fraud check or an analytics sink) by subscribing to an existing event, with zero changes to the producer. EDA is built on the primitives of message queues and publish-subscribe, and it brings characteristic challenges, eventual consistency (the system is correct over time, not instantaneously), the need for idempotent consumers (events can be redelivered), event ordering, and the difficulty of tracing a request that hops across many asynchronous handlers (which is why distributed tracing matters). Done well, EDA scales gracefully and isolates failures; done poorly, it becomes a tangle of implicit dependencies that is hard to reason about. For an AI agent working in such a system, a shared memory of the event catalog, which events exist, who emits them, who consumes them, is invaluable for reasoning about cause and effect across services.