Event-Driven Architecture

Both are messages, but they carry different intent:

• A command says "do this". It's directed at a specific handler. Imperative. May fail or be rejected. Example: ChargeCard(orderId=42, amount=99.99).
• An event says "this happened". It's broadcast to anyone interested. Past tense. Immutable. Example: OrderPlaced(orderId=42, amount=99.99, userId=7).

The difference matters. Commands are 1-to-1; events are 1-to-many. A new consumer can subscribe to an event without the producer ever knowing. That's the structural property that makes event-driven systems extensible — and the same property that makes them harder to reason about.

What event-driven architecture gives you, in order of value:

• Decoupling: the order service emits OrderPlaced; the email, inventory, and analytics services react. The order service doesn't import any of them.
• Extensibility: a new team wants to react to orders → they subscribe; no change to the producer.
• Async load-shedding: heavy work moves off the request path. Users get fast "accepted" responses; processing happens in the background.
• Auditability: a stream of past events is itself an audit log of every meaningful state change.

What it costs: every service-to-service interaction becomes async, which forces eventual consistency on the product side. "I just placed an order; why isn't it in my order history yet?" is the daily UX cost.

Two ways to coordinate multi-step business processes:

• Choreography: each service listens for events and reacts. There's no central coordinator. "OrderPlaced → InventoryReserved → PaymentRequested → PaymentCharged → OrderConfirmed". Each transition is owned by the service that performs it.
• Orchestration: a central service (often a workflow engine like Temporal, Step Functions, or Airflow) tells each service what to do, in order. The orchestrator owns the process state.

Choreography is simpler to bootstrap but harder to reason about — "what's the full flow?" requires reading every service. Orchestration centralises the flow but makes the orchestrator a critical dependency. Most teams use orchestration for explicit business processes ("checkout") and choreography for cross-cutting reactions ("send a welcome email when a user signs up").

Each service reacts to the event that matters to it.

Conventional design stores current state. Event sourcing flips this: store every event that ever happened, derive current state by replaying them.

Example, for a bank account:

Event log:
  AccountOpened(id=1, owner=Alice)
  Deposited(id=1, amount=100)
  Withdrew(id=1, amount=30)
  Deposited(id=1, amount=50)

Current state (derived): balance = 120

Upsides: total auditability, easy time-travel debugging ("what was the balance last Tuesday?"), ability to add new projections without rewriting history.

Downsides: replays get slow as the log grows (mitigated with snapshots), schema changes to events are painful, every query against current state is a derivation. Use it when audit/history is genuinely a first-class requirement (banking, healthcare, regulated industries). Don't use it because it sounds elegant.

Command Query Responsibility Segregation says: the model you use to write doesn't have to match the model you use to read.

• Write model: optimised for command validation. Normalised, transactional, often event-sourced.
• Read model: optimised for queries. Denormalised, pre-aggregated, possibly in a different store (Elasticsearch, a cache, a wide-column DB).
• The link: every write emits an event; the read model subscribes and updates.

CQRS is most useful when reads and writes have wildly different shapes — e.g. you write "events" but read "a list of all orders with totals by category by month". The complexity is real (you now have to keep two stores in sync), so reserve it for cases where a single model genuinely fights the workload.

Event-driven systems are eventually consistent across services. The user-visible symptoms:

• Place an order; it's not in your list yet.
• Update your profile; some part of the app still shows the old version.
• Like a post; the count doesn't update for 200ms.

Mitigations:

• Optimistic UI: the client updates immediately, then reconciles. The user sees instant feedback; the system catches up.
• Read-your-writes within a single service: the writer's own service should be strongly consistent even if cross-service is eventual.
• Versioned reads: client passes a "min version" with reads; server waits briefly if the read model is behind.
• Be honest in the UX: "processing your order" pages with a spinner are honest; pretending success then surprising the user with a backend failure 5 seconds later is not.

Most EDA UX bugs come from teams treating async like sync. Plan for the gap.

EDA is overkill (or actively harmful) when:

• Strong consistency is mandatory: you can't tolerate "the email said your card was charged but the order isn't there yet". Some financial flows fall here; use a synchronous transaction instead.
• Single team, single service: the decoupling buys you nothing. The async complexity is pure tax.
• Tight request-response shapes: "user submits form, expects success/failure within 200ms". Async events don't fit.
• Low data velocity: a system processing 100 events/day doesn't need Kafka. A cron job and a database table will do.

The decision to go event-driven should be driven by independent service evolution and fan-out needs, not by it being the fashionable architecture this year.