Event-driven architecture (EDA) is a software design pattern in which services communicate by producing and consuming events rather than calling each other directly. A single event, like an order being placed, can trigger downstream behavior across many independent services without the producer knowing or caring who is listening. This decoupling is what makes EDA scale.

This guide covers what event-driven architecture actually means in production, the patterns most teams reach for, the brokers and platforms that power it, and where the operational complexity lives. It also explains when not to use EDA, since the model adds real overhead that pays off only above a certain system size.

What Event-Driven Architecture Is

In a request-response system, a service calls another service and waits for a result. The caller is coupled to the callee: it has to know the address, the API, and the contract, and it shares a fate with the callee at runtime.

In an event-driven system, a service publishes an event to a broker. The broker delivers the event to any subscribers that have registered interest. The publisher does not know who the subscribers are, how many there are, or whether any of them succeed. Subscribers can come and go independently.

An event-driven system has three structural pieces:

• Event producers. Services that detect a state change and publish an event describing it. Examples: a checkout service publishing OrderPlaced, an auth service publishing UserSignedUp.
• Event routers (also called brokers, buses, or streams). Infrastructure that receives events and delivers them to subscribers. Examples: Kafka, NATS, AWS SNS+SQS, GCP Pub/Sub.
• Event consumers. Services that subscribe to specific event types and react to them. A UserSignedUp event might be consumed by a billing service that creates a customer record, an analytics service that logs the signup, and a notification service that sends a welcome email. None of them block the producer.

The producer and consumers run independently. Adding a fourth consumer (say, a fraud-detection service) does not require touching the producer. That is the property EDA exists to provide.

EDA vs Request-Response

The two models are complementary, not opposed. Most production systems use both. The right question is which to use for which interaction.

Request-response fits when you need the result before continuing. A frontend asking the API for a user's profile is request-response. A service charging a credit card and waiting for an authorization code is request-response. The caller cannot proceed without the answer.

Event-driven fits when the producer's job is finished before the consumers' work begins. After an order is placed, the order service has nothing more to do; sending the confirmation email, updating inventory, and notifying the warehouse are all consumer concerns. The producer should not block on any of them.

The cost of using request-response where events would fit is coupling. Every consumer becomes a dependency the producer has to know about, deploy alongside, and degrade with. The cost of using events where request-response would fit is misleading code: the caller looks like it's done when it's actually still waiting for something to happen elsewhere.

EDA vs Microservices

The two are often discussed together but they are different things. Microservices is an architectural style for splitting a system into independently deployable services. Event-driven is a communication pattern those services can use to talk to each other.

You can build microservices that talk via REST and gRPC and never publish a single event. You can also build a monolith that uses an internal event bus to decouple modules. EDA is most associated with microservices because it solves the problem microservices create: how do you coordinate work across many services without coupling them tightly?

For a deeper comparison, see our guide to microservices.

Common Event-Driven Patterns

A handful of patterns show up repeatedly in production EDA systems. Understanding them is the difference between an event-driven system that ages well and one that becomes a tangled queue of side effects.

Event Sourcing

Event sourcing stores every state change as an immutable event in an append-only log. Current state is derived by replaying events. The event log itself becomes the source of truth, and the database tables are projections.

The benefit is auditability and time travel: you can rebuild the state at any past moment by replaying events up to that point. The cost is complexity. Schema changes in events have to be handled carefully, snapshotting is required for performance, and reasoning about the system requires understanding the log, not just the current row.

Event sourcing is most valuable in domains where the history matters as much as the current state: finance, audit-heavy regulated systems, and anything that needs reliable rewind.

CQRS (Command Query Responsibility Segregation)

CQRS splits the write path from the read path. Commands change state by emitting events; queries read from purpose-built read models that are kept up to date by consuming those events.

CQRS pairs naturally with event sourcing but does not require it. The advantage is that read and write models can scale and evolve independently. A read model for a dashboard can denormalize aggressively for fast queries; the write model stays normalized for correctness.

CQRS adds eventual consistency between writes and reads. If your UI expects a write to be visible the next millisecond, you need to design around the lag.

Saga

Sagas coordinate long-running, multi-step business processes across services without distributed transactions. Each step publishes an event indicating success or failure, and compensating events undo earlier steps when something fails downstream.

A booking saga might look like: reserve seat, charge card, send confirmation. If the charge fails, a compensating event releases the seat. Sagas trade ACID transactions for eventual consistency with explicit recovery logic.

Two implementation styles dominate: choreography (each service decides what to do based on events it observes) and orchestration (a coordinator service issues commands and reacts to results). Choreography is simpler at small scale; orchestration is easier to reason about as the saga grows.

Outbox Pattern

The outbox pattern solves a subtle but common bug: a service updates a database row and then publishes an event about it, and the two operations are not atomic. If the database commits but the event publish fails, the system is now in an inconsistent state.

The outbox pattern fixes this by writing the event into an outbox table inside the same database transaction as the state change. A separate process polls the outbox and publishes pending events to the broker. The atomicity of the database guarantees that either both happen or neither does.

When to Use Event-Driven Architecture

EDA pays for itself when:

• You have multiple consumers of the same state change. Order placed, user signed up, payment received. If three or more services care about an event, EDA removes the explicit coupling between the producer and each consumer.
• You need to add new consumers without touching the producer. A fraud-detection service that subscribes to OrderPlaced can be deployed independently. Without EDA, every new consumer requires changes to the order service.
• Producer and consumer have very different latency or scaling profiles. The producer is a high-throughput API; the consumer is a slow analytics job. With events, the broker absorbs the impedance mismatch.
• You're integrating across organizational boundaries. Different teams or different companies. Event contracts let teams move at different speeds without blocking each other on synchronous coordination.
• You need an audit trail. Events are naturally a log of what happened. Even without full event sourcing, durable events make the system inspectable after the fact.

When Not to Use EDA

Event-driven systems are harder to reason about, harder to debug, and harder to test than synchronous ones. Avoid them when:

• The interaction is genuinely synchronous. If A needs B's response to do its job, an event is the wrong primitive. Use a direct API call.
• You have only one consumer per event. A message queue between two services is not really an event-driven architecture; it's a queue. The decoupling benefit barely exists.
• The system is small and the team is small. EDA buys you decoupling. If you don't have multiple teams or multiple consumers, you're paying complexity tax for benefits you won't use.
• You're not ready to operate it. Distributed tracing, dead-letter queues, idempotency, schema evolution. EDA without these is a debugging nightmare.

Event-Driven Architecture Tools and Brokers

The tool you pick has a large effect on what your system feels like to operate. Brokers fall into a few buckets:

Tool	Style	Strengths	When to Pick
Apache Kafka	Log-based, partitioned streaming	Very high throughput, replay, retention, mature ecosystem	High-volume pipelines, event sourcing, log-as-source-of-truth systems
Redpanda	Kafka-compatible, single-binary	Kafka semantics with simpler ops and lower latency	Teams who want Kafka without the JVM/ZooKeeper overhead
NATS / NATS JetStream	Lightweight pub/sub with optional streaming	Simple operations, low latency, good for edge and IoT	Service-to-service messaging where Kafka is overkill
RabbitMQ	Traditional message broker (AMQP)	Mature, flexible routing, well-documented	Task queues, complex routing topologies, brownfield integrations
AWS EventBridge	Managed event bus	Serverless, integrates with AWS services, schema registry	AWS-native systems, event routing across SaaS and AWS
AWS SNS + SQS	Pub/sub with durable queues	Simple, cheap, works at any scale	Most AWS-hosted backends; the practical default
GCP Pub/Sub	Managed pub/sub	Push and pull subscribers, ordering keys, exactly-once	GCP-native systems, mixed batch and streaming workloads
Azure Service Bus / Event Grid	Managed messaging on Azure	Enterprise feature set, transactions, sessions	Azure-native systems

A common misstep is picking Kafka because it's the brand-name option, when SNS+SQS or NATS would solve the problem with a tenth of the operational overhead. Match the broker to the volume and patterns you actually have, not the ones you imagine you'll have at scale.

Operational Realities

The architecture diagram is the easy part. The day-to-day cost of running an event-driven system shows up in five places:

Debugging. A bug in a request-response system has a clean stack trace. A bug in an event-driven system requires reconstructing what happened across multiple services and time windows. Distributed tracing is not optional. See our distributed tracing for microservices guide.

Idempotency. Most brokers guarantee at-least-once delivery, which means consumers will sometimes see the same event twice. Every consumer has to be safe to re-run. Idempotency keys, dedup tables, or operations that are naturally idempotent.

Ordering. Strict global ordering is rarely available and rarely free. Most systems get partition-level ordering at best. Design your events so that ordering matters within a key (one user's events) but not across keys.

Failure handling. Dead-letter queues catch events that consumers repeatedly fail to process. Without them, a single bad event can stall a subscription forever. With them, you have a place to go look when things break.

Schema evolution. Events outlive the code that wrote them. A consumer reading an event published a year ago should not break because someone renamed a field. Schema registries (Avro, Protobuf with backward-compat checks) or strict additive-only conventions are the usual answer.

For a deeper look at queue-based vs pub/sub patterns, see Message queues vs Pub/Sub.

Pub/Sub as the Foundation for EDA

The simplest, most common implementation pattern for event-driven architecture is Pub/Sub: a producer publishes to a topic, the broker fans out to all subscribers. This is what AWS SNS+SQS, GCP Pub/Sub, NATS, and Kafka (in its simplest form) all provide.

The reason Pub/Sub dominates is that it covers the 80% case directly: multiple consumers want to react to the same state change, the producer should not be coupled to any of them, and the broker absorbs the coordination. More elaborate patterns (event sourcing, CQRS) build on top of this primitive.

Learn more about Pub/Sub.

How Encore Approaches Event-Driven Architecture

Most of the operational complexity in EDA comes from coordinating four moving parts: the broker, the producer code, the subscriber code, and the deployment pipeline that wires them together across local, staging, and production environments. Each environment needs the broker provisioned, credentials handled, subscriptions created, and observability hooked up.

Encore takes a different approach. You declare topics and subscriptions as typed objects in your TypeScript or Go code, and the framework provisions the broker, wires subscriptions, generates traces, and handles environment-specific configuration automatically. The framework has over 11,000 GitHub stars and is used in production at companies including Groupon.

Defining a topic in TypeScript:

import { Topic, Subscription } from "encore.dev/pubsub";

export interface OrderPlaced {
  orderID: string;
  customerID: string;
  total: number;
}

export const orderPlaced = new Topic<OrderPlaced>("order-placed", {
  deliveryGuarantee: "at-least-once",
});

// In a different service: subscribe and react
const _ = new Subscription(orderPlaced, "send-confirmation", {
  handler: async (event) => {
    await sendEmail(event.customerID, event.orderID);
  },
});

const __ = new Subscription(orderPlaced, "update-inventory", {
  handler: async (event) => {
    await updateStock(event.orderID);
  },
});

The equivalent in Go:

import "encore.dev/pubsub"

type OrderPlaced struct {
  OrderID    string
  CustomerID string
  Total      float64
}

var OrderPlacedTopic = pubsub.NewTopic[*OrderPlaced]("order-placed", pubsub.TopicConfig{
  DeliveryGuarantee: pubsub.AtLeastOnce,
})

// Publish from anywhere:
OrderPlacedTopic.Publish(ctx, &OrderPlaced{...})

The publisher does not know what infrastructure is behind the topic. Encore picks the appropriate broker per environment:

• NSQ in local development, started automatically with encore run
• AWS SNS+SQS for environments deployed to AWS
• GCP Pub/Sub for environments deployed to GCP

Subscriptions, dead-letter queues, IAM policies, and per-environment credentials are generated from the code. Distributed tracing across publishers and subscribers is built in, so debugging an event flow is the same experience locally and in production.

The result is that the operational layer EDA usually demands gets handled by the framework, and the application code stays focused on what events the system has and how to react to them.

Conclusion

Event-driven architecture is a powerful tool when you have multiple independent consumers reacting to the same state changes, organizational or scaling boundaries between services, or a need for an audit-grade history of what happened. It is the wrong tool for synchronous interactions, small systems with single consumers, or teams without the operational maturity to run it well.

Start with Pub/Sub as the primitive. Layer on patterns (event sourcing, CQRS, saga, outbox) only when the system actually needs them. Pick a broker that matches your volume and your team's operational comfort, not the one with the loudest brand. And invest in distributed tracing, idempotency, and dead-letter queues from day one, because retrofitting them after a production incident is a tax you will pay several times over.

Related Reading

• Pub/Sub explained
• Microservices
• Distributed tracing for microservices
• Event-driven microservices on AWS: Encore vs DIY
• Message queues vs Pub/Sub

Related Blog Posts

• Event-Driven Architecture: What you need to know
• Making a Business Case for an Event-Driven Architecture
• Building for Failure
• Long-Term Ownership and Maintenance of an Event-Driven System