EDA Decision Matrix Tool
Interactive flow analyzer. Describe your system's intent, topology, and constraints, and get a concrete recommendation: synchronous API, event choreography, or orchestration. Includes pattern blueprints and preset scenarios.
What is event-driven architecture?
In a traditional request-response model, Service A calls Service B directly and waits for a response. In an event-driven model, Service A publishes a fact about something that happened, and any number of other services can react to it independently. The producer doesn't know who is listening. The consumers don't need to be available at the same moment the event is produced.
This separation is what makes event-driven design attractive for large platforms. A new service can start consuming an existing event without touching the producer. Different parts of the system can evolve at different speeds. Background work, like sending a welcome email or updating a search index, doesn't need to block the user's request.
But event-driven architecture is not free. You trade direct coupling for a different kind of complexity: event schemas that need versioning and ownership, duplicate message handling, eventual consistency instead of immediate answers, observability across multiple services, and the risk that a complex business process becomes invisible because it's spread across many independent reactions. The goal is to use events where they genuinely help, and not force them where they don't.
Events, commands, and queries are different things
A lot of confusion in distributed system design comes from mixing up three types of messages that have a fundamentally different relationship with time.
An event describes something that already happened. It is a fact about the past. CustomerRegistered, PaymentAuthorized, OrderCancelled. Events are immutable and describe a completed state change. The source system doesn't need to care what anyone does with the information.
A command asks for something to happen in the future. ReserveInventory, CreateShipment. Commands can be accepted or rejected. They have an intended recipient. They are not the same as events, even if they travel over the same broker.
A query asks for information right now. The caller needs an answer. GetCustomerProfile, CalculatePrice. Queries are synchronous by nature. Routing a query through an event broker and polling for the result adds latency and complexity for no benefit.
When these distinctions stay clear, the architecture is easier to reason about. When they blur, you end up with things like events named OrderCreated that secretly expect three downstream services to do specific things in a specific order, and nobody owns what happens when one of them fails.
Orchestration vs choreography
Even when you decide to use events, you still need to choose how the overall process is managed. The two main approaches are choreography and orchestration.
In choreography, each service reacts to events it cares about and publishes new events in response. There is no central coordinator. The overall process emerges from the combined reactions of independent services. This works well when the reactions are genuinely independent: sending a welcome email, updating an analytics counter, syncing a CRM record. Each service can own its piece without anyone else needing to know about it.
In orchestration, a single workflow, process manager, or coordinator owns the flow. It decides what happens next, handles retries, manages timeouts, and triggers compensation if something goes wrong. This is the right choice for complex business processes where step order matters, failures need explicit handling, and someone needs to be able to answer "where is this order right now?"
The practical test is simple: if the process gets stuck, who is responsible for knowing where and why? If the answer is "everyone a little bit," that usually means orchestration is the right tool. If each service can independently handle its own reaction with no effect on anyone else, choreography may be enough.
Choosing between choreography and orchestration
| Signal | Suggests choreography | Suggests orchestration |
|---|---|---|
| Step ordering | Steps are independent | Steps must run in sequence |
| Failure handling | Each service handles its own | Compensation logic needed |
| Process visibility | Not needed | Business needs to see status |
| Ownership | Each service owns its reaction | One owner for the outcome |
Articles & Tools
In-depth articles and interactive tools covering event-driven design decisions, patterns, and trade-offs.
EDA Orchestration and Patterns
Orchestration vs choreography in practice, five good patterns to follow (outbox, idempotency, schema versioning, event ownership, business vs technical events), five anti-patterns to avoid, and a practical decision guide.
Message Broker Comparison: Kafka vs RabbitMQ vs SQS - coming soon
When to use each broker, ordering guarantees, delivery semantics, and how the choice affects your consumer design.
Domain Events vs Integration Events - coming soon
Why the boundary between domains matters for event design, how to version events across team boundaries, and when to translate between internal and external event schemas.
Event Sourcing vs Event-Driven Architecture - coming soon
Two ideas that are often confused. Event sourcing stores state as a sequence of events. Event-driven architecture uses events for communication. You can use either without the other.
Frequently Asked Questions
Event-driven architecture is a design approach where services communicate by producing and consuming events rather than calling each other directly. A service publishes a fact about something that happened, and other services react to it independently. This reduces direct coupling and makes it easier to add new consumers without changing the producer.
An event describes something that already happened: CustomerRegistered, PaymentAuthorized. A command asks for something to happen: ReserveInventory, CreateShipment. A query asks for information right now: GetCustomerProfile, CalculatePrice. Mixing these up is one of the most common sources of hidden complexity in distributed systems.
In choreography, services react independently to events with no central coordinator. In orchestration, one workflow or process manager owns the flow and directs each step. Choreography works well for simple, independent reactions. Orchestration is better when a business process needs clear ownership, step ordering, retry logic, or compensation on failure.
When the caller needs an immediate answer, a synchronous API is usually simpler. Events add real overhead: schemas, versioning, retries, duplicate handling, and observability. If a flow is essentially a query or a direct action with a single recipient, routing it through a message broker adds complexity without a corresponding benefit.
The outbox pattern solves the problem of publishing an event atomically with a database write. Instead of updating the database and then publishing to a broker as two separate steps, you write both the business change and the event record in the same database transaction. A background process then reads the outbox and publishes. This prevents the gap between a committed state change and a failed event publish.