Event-Driven Architecture

Direct calls tie every component's availability to every other's

In a system built entirely on direct request/response calls, a service can only do its job if every service it depends on is up, right now. As the number of components grows, that web of live dependencies becomes both fragile and hard to reason about — and adding a new consumer of existing data means changing the producer's code.

Producers emit facts; consumers react independently

This is the architectural style, not a single pattern — Publisher-Subscriber (delivery mechanism), Event Sourcing (storing state as events), Saga (coordinating a workflow via events), and Domain Events (in-process reactions) are all specific patterns that live under this umbrella. What ties them together: components emit events describing things that happened, and other components subscribe and react, without either side calling the other directly or waiting on an immediate response.

A minimal event backbone tying several patterns together

This is deliberately the smallest possible sketch — the same `bus` primitive shown here is what Publisher-Subscriber, Saga, and Domain Events each build on for their specific purpose.

const bus = new EventTarget();

// Order Service: emits a fact, doesn't know or care who's listening.
function placeOrder(id) {
  console.log(`orders: placed ${id}`);
  bus.dispatchEvent(new CustomEvent("OrderPlaced", { detail: { id } }));
}

// Inventory Service: reacts independently — this is choreography (see Saga).
bus.addEventListener("OrderPlaced", (e) => {
  console.log(`inventory: reserving stock for ${e.detail.id}`);
});

// Analytics: also reacts independently — this is Publisher-Subscriber fan-out.
bus.addEventListener("OrderPlaced", (e) => {
  console.log(`analytics: logged order ${e.detail.id}`);
});

placeOrder("order-1");
// Adding a third subscriber later needs zero changes to placeOrder.

Trade-offs

• Loose coupling at the system level — Producers don't need consumers to be available, or even to exist yet, to do their own job.
• New capabilities without touching existing code — A new consumer of an existing event stream is purely additive.
• Harder to trace and reason about globally — With no direct call chain, understanding an end-to-end flow usually requires distributed tracing across many independently-reacting components.