← All topics
🏗️ Architecture

Event-Driven Architecture

Producers, consumers, choreography vs orchestration.

Services communicate by publishing/reacting to events rather than calling each other directly — producers don't know or care who (if anyone) is listening, which is the core decoupling payoff.

Choreography vs Orchestration: in choreography, each service reacts to events and emits its own, with no central coordinator — the overall process emerges from independent reactions (this is the NServiceBus quickstart's shape: Sales publishes OrderPlaced, Billing reacts independently, no one "in charge" of the whole flow). In orchestration, a central process (a Saga/state machine) explicitly tells each participant what to do next and tracks overall progress. Choreography scales better and decouples further; orchestration is easier to reason about/debug for genuinely multi-step processes with real branching logic and failure compensation — know both exist and the tradeoff, don't present either as universally correct.

Eventual consistency is the accepted tradeoff: after OrderPlaced is published, there's a window where Billing hasn't processed it yet — the system as a whole is consistent eventually, not instantly, in exchange for the loose coupling.

Flashcards (3)

What's the core decoupling benefit of event-driven communication over direct service-to-service calls?
tap to reveal answer
The publisher doesn't need to know who (if anyone) is listening, or what they'll do — consumers can be added or removed without changing the publisher at all, unlike a direct call which hard-codes the dependency.
Choreography vs Orchestration — give the core difference and one tradeoff of each.
tap to reveal answer
Choreography: services independently react to and emit events, no central coordinator — highly decoupled but harder to see/debug the overall process. Orchestration: a central Saga/coordinator explicitly directs each step — easier to reason about complex multi-step flows with compensation, but reintroduces some central coupling.
What does 'eventual consistency' mean in an event-driven system, and why is it an accepted tradeoff rather than a bug?
tap to reveal answer
After an event is published there's a window before all consumers have processed it, so the system isn't instantaneously consistent across services — it's accepted in exchange for loose coupling and independent scalability; the alternative (synchronous calls to guarantee immediate consistency) reintroduces tight coupling.