Event-Driven Architecture

Order placed. Now: charge card, decrement inventory, send confirmation email, notify warehouse, update analytics, trigger fraud check, alert support if VIP. Six things must happen.

The naive "request-response" approach: the order service synchronously calls all six. Tightly coupled. Slow (sum of all six latencies). One fails → everything fails. Adding a seventh thing requires deploying the order service.

Event-driven architecture (EDA): the order service publishes one event ("OrderPlaced") and walks away. The six interested services subscribe, each reacts independently. Loose coupling. Async. New consumers added without touching the producer. Modern systems run on this pattern.

How does a multi-step business process unfold? Two styles:

Choreography — each service listens to events and decides what to do. No central conductor. Order placed → Payment Service fires Charge → emits PaymentSucceeded → Inventory Service decrements → emits InventoryReserved → Shipping Service creates label.

Pros: services don't depend on each other knowing them. Easy to add a new step (just subscribe). Resilient — no single conductor to fail.

Cons: business flow is implicit, scattered across services. "Where's the order in this flow?" is hard to answer. Debugging requires distributed tracing.

Orchestration — a workflow service explicitly drives the steps. "Order Saga" calls Payment, then Inventory, then Shipping. Knows the sequence. Handles compensations.

Pros: business logic visible in one place. Easy to debug ("show me Order 42's saga state"). Compensation logic clear.

Cons: orchestrator becomes a complex service. Single point of coordination.

-- Dual-write problem: write to DB + emit Kafka event atomically.
-- Solution: outbox table in same transaction as business write.

CREATE TABLE outbox (
  id            BIGSERIAL PRIMARY KEY,
  aggregate_id  BIGINT NOT NULL,
  event_type    TEXT NOT NULL,
  payload       JSONB NOT NULL,
  created_at    TIMESTAMPTZ DEFAULT now(),
  published     BOOLEAN DEFAULT false
);

-- Application writes both in one transaction:
BEGIN;
  INSERT INTO orders (...) VALUES (...);
  INSERT INTO outbox (aggregate_id, event_type, payload)
  VALUES ($orderId, 'OrderCreated', $payloadJson);
COMMIT;

-- Separate CDC process (Debezium) or polling worker reads new rows
-- from outbox, publishes to Kafka, marks published=true.

EDA is sold as universally good. It isn't. Real downsides:

Eventual consistency everywhere. Order placed at T=0; warehouse sees it at T+200ms. Customer immediately calls support: "where's my order?" Support service hasn't received the event yet. Real friction.

Debugging gets harder. A single user action generates events across 8 services. Tracing the causal chain requires distributed tracing (OpenTelemetry) and event correlation IDs. Painful without good tooling.

Schema evolution becomes a coordination problem. Add a field to OrderPlaced → 12 consumers may break. Need schema registry (Avro, Protobuf), strict backwards-compatibility rules.

Duplicate / out-of-order delivery. Most brokers are at-least-once. Consumers must be idempotent. Out-of-order events break naive state machines.

Hidden coupling reappears. "Producer doesn't know consumers" sounds great until two consumers each subtly depend on the producer's event timing or ordering. The coupling moves from APIs to event semantics — equally hard to change.

News feed uses events for fan-out (PostCreated → fan-out workers). E-commerce checkout is an orchestrated saga. Notification system is fundamentally a downstream consumer of events from every other service. Distributed job scheduler dispatches work via events.