Event-Driven Architecture

Event-driven architecture (EDA) treats state changes as first-class events. When something happens — an order is placed, a payment fails, a user signs up — the service publishes an event describing what occurred. Other services subscribe and update their own state or trigger side effects. No service calls another directly; they react to facts.

This creates temporal decoupling: the publisher does not know or care who listens. New consumers can be added without changing the producer. The cost is eventual consistency — you cannot assume all services see the new state immediately. Event sourcing takes EDA further by storing events as the source of truth and rebuilding state by replaying them.

Before

Direct orchestration

1// Order service knows every downstream step2async function placeOrder(data) {3  const order = await db.create(data);4  await inventory.reserve(order);5  await payment.charge(order);6  await analytics.track(order);7  return order;8}

After

Event-driven choreography

1// Order service publishes a fact and stops2async function placeOrder(data) {3  const order = await db.create(data);4  await eventBus.publish('OrderPlaced', {5    orderId: order.id,6    items: order.items,7    total: order.total,8  });9  return order;10}11// Inventory, Payment, Analytics each subscribe on their own

Check your understanding

What should an event describe?Show answerHide answer
Answer
A fact that already happened (OrderPlaced), not an imperative command to another team’s service.
What consistency model do you usually accept?Show answerHide answer
Answer
Eventual consistency — subscribers update on their own timeline.
What is the main coupling benefit?Show answerHide answer
Answer
Producers need not know the full set of consumers; new listeners can subscribe later.