Event-driven architecture (EDA) is a software design where components communicate by producing and consuming events rather than calling each other directly. A producer emits an event when something happens. Any number of consumers can react to it independently — no producer needs to know what consumers exist.
This isn't a new idea. Banks, telcos, and trading systems have used EDA for decades. What changed in 2024-2026 is that AI agents make EDA the default architecture for a new class of applications — because agents fundamentally react to things happening in the world, not to API calls.
This guide covers the core concepts of EDA, the patterns that show up in production agent systems, and the failure modes you have to design for.
The core concepts
Three primitives:
- Event — an immutable record that something happened. "Payment succeeded for customer X at time Y." Past tense, factual.
- Producer — the system that emits events. Stripe is a producer when it fires
payment_intent.succeeded. Your form-submission endpoint is a producer. - Consumer — a system that reacts to events. Your fulfillment service. Your CRM. Your AI agent.
The defining feature: producers don't know about consumers. They emit events into a pipeline; consumers subscribe to what they care about. Adding a new consumer doesn't require changes to the producer.
The pipeline in the middle — the thing that moves events from producers to consumers — is the event broker (or "event bus" or "relay layer"). Common implementations: Kafka, RabbitMQ, AWS SNS/SQS, EventBridge, GCP Pub/Sub, and webhook relays like Hooksbase.
EDA vs request-response
In a request-response system, your code calls a function (or HTTP endpoint) and waits for a result. Tight coupling: caller knows the callee, blocks until it returns.
In an event-driven system, your code emits an event and continues. Anyone listening reacts. Loose coupling: producer doesn't know the consumers, doesn't wait for them.
Both have their place:
- Request-response is right when the caller needs the result immediately to continue (lookup, validation, synchronous computation).
- Event-driven is right when the action and reaction are independent in time, the consumers are unknown or many, or the producer shouldn't block on consumer behavior.
Most production systems blend both: HTTP APIs for synchronous operations, an event stream for async reactions.
Why AI agents need EDA more than classical software
Three properties of agents push them toward EDA:
1. Triggers come from the world, not from a user click. A classical web app reacts to user clicks. An AI agent reacts to a payment failing, an email arriving, a PR being opened, a scheduled tick. Events from outside drive the loop. An event-driven architecture is the natural shape.
2. Side effects are expensive and non-deterministic. A classical webhook handler is fast and idempotent — retries are safe. An agent calls an LLM (cost), runs tools (real-world effects), and may take seconds or minutes. You can't afford to retry naively. EDA's emphasis on durable events, idempotent consumption, and replay matches what agents need.
3. Multiple agents and downstream services need the same event. A payment_failed event might trigger a recovery agent, a CS notification, a billing-database update, an audit log entry, and an analytics dispatch. In a request-response model, the producer would have to call all of those — coupling everything together. In EDA, the producer emits once; each consumer subscribes independently.
The combination — world-driven, expensive consumers, multiple consumers — is what makes EDA the default for production agent systems.
Common EDA patterns for agents
Event notification — the event is small and just says "X happened, look it up if you care." Consumers fetch additional context via APIs. Trade-off: small events but more API traffic. Stripe's webhook style.
Event-carried state transfer — the event includes everything a consumer might need. Trade-off: bigger events but no follow-up calls. Most modern provider webhooks lean here.
Pub/sub — broker holds events; consumers subscribe to topics. Many consumers can react to the same event independently. SQS, SNS, Kafka, Redis Pub/Sub, EventBridge all implement variants.
Event sourcing — the event log is the source of truth. Current state is a fold over the events. See the event sourcing guide for the full pattern.
Choreography — components react to events and emit new events; no central orchestrator. Loosely coupled, hard to reason about end-to-end.
Orchestration — a central component (a workflow engine, often) drives the sequence by emitting commands and listening for responses. Easier to reason about, more centralized.
Most production agent systems use a mix: pub/sub for the event distribution, event-carried state transfer for the payloads, and orchestration where the agent's flow is the central concern.
Failure modes you have to design for
EDA pushes complexity from the producer-consumer coupling into the event pipeline. The three failure modes that bite every team:
1. Out-of-order delivery. Events for the same entity (e.g. a single subscription) can arrive at consumers in the wrong order. The fix: either order them at the source (FIFO topics, partition keys) or design consumers to be order-tolerant.
2. Duplicate delivery. At-least-once delivery means you'll see the same event twice. The fix: idempotency keys on every event; consumers refuse to re-process. See the idempotency guide for the full pattern.
3. Missed events. Outages, broker failures, consumer downtime — events can be lost between producer and consumer. The fix: durable storage in the broker, retries with backoff, a dead-letter queue for terminal failures, and a recovery path (replay or backfill).
These failure modes are not exotic. They show up in every production EDA system, eventually. The good news: the solutions are well-understood. The bad news: they're solutions you have to actually build (or pay a vendor for) — and most teams underestimate the effort.
Where Hooksbase fits in an EDA
Hooksbase is the event-driven layer for AI agents at the boundary of your system. It accepts HTTP, email, and form events on every tier, adds scheduled cron on Starter+, persists accepted events, routes each event through programmable rules to the selected destination, and supports standard EDA primitives: idempotency when producers send keys, retries with backoff, Pro+ strict FIFO and throttling, DLQ, deterministic replay while payloads are retained, and Pro+ event drains for observability.
For agents specifically, this means: the events your agent reacts to flow through one well-understood pipeline regardless of channel, and the failure modes that EDA forces you to think about have first-class solutions instead of being your team's quarter-long project.
Where to go next
- Event sourcing in plain English for the deeper pattern that EDA often pairs with
- What is a message queue? for when queues fit and when webhooks beat them
- Event infrastructure for AI agents for the architectural argument applied to agents specifically
- Routing, transforms, and replay for AI agents for the relay-side patterns