InterviewKata
Software architecture · Level 3: Architecture styles · Module 14 of 46

Event-driven architecture

In most systems, one component tells another what to do. In an event-driven system, components announce what happened ("order placed", "payment taken") and anyone interested reacts. That one change gives extraordinary scalability, responsiveness and ease of adding new behaviour, and makes the overall workflow harder to see, test and recover when something fails. This module covers both topologies, how events differ from messages, and the event design mistakes that hurt most.

See it builtThe Architecture styles track builds this style for one bike-share app, with code you can run: 10 Event-driven.

1. The idea

A newsroom versus a relay race. In a relay, each runner hands the baton to one named next runner; if someone drops it, the race stops. In a newsroom, a reporter shouts "fire at the docks!" and everyone who cares reacts at once: the photographer grabs a camera, the editor clears page one, the website team starts a live blog. The reporter doesn't know or care who reacted. New people can start listening without anyone changing how reporters work.

Events vs messages

EventMessage (command)
MeaningSomething happened: OrderPlacedPlease do something: ChargeCard
TensePastImperative
ReceiversAny number; the sender doesn't know themOne intended receiver
Usual channelA topic (publish/subscribe)A queue (point to point)

Two topologies

Broker topology (choreography)

No coordinator. An initiating event goes to a topic; each event processor reacts, does its part and publishes a derived event ("payment taken"), which others react to in turn. Highly decoupled, fast and extensible; nobody owns the whole workflow, so errors and overall state are hard to manage.

Mediator topology (orchestration)

An event mediator receives the initiating event and directs the steps, sending commands to processors in order and handling their replies and failures. Better control, error handling and visibility; more coupling to the mediator, and it can become a bottleneck.

How it rates

CharacteristicEvent-drivenService-based
Partitioningtechnicaldomain
Quanta1 to many1 to many
Cost★★★★★★★★★★
Simplicity★★★★★★★★★★
Scalability★★★★★★★★★★
Elasticity★★★★★★★★★★
Fault tolerance★★★★★★★★★★
Evolvability★★★★★★★★★★
Deployability★★★★★★★★★★
Testability★★★★★★★★★★
Performance★★★★★★★★★★

Our qualitative ratings, 1 to 5 stars, more is better (for cost, more stars = cheaper). They compare styles in general; your context can move any of them.

2. How it works

Broker topology: everyone reacts

Mediator topology: someone in charge

The same order, with an event mediator. Watch the same payment failure handled.

3. Try it yourself

Anemic or full events?

An anemic event carries only an ID (OrderPlaced {id: 81}), so every consumer calls back to fetch the details. A full event carries the data consumers need. Set the load and payload and see the cost.

500
6

Assumes an ID-only event is about 0.1 KB, key fields (customer, items, total, address) about 1 KB, and the full order with history about 8 KB; with key fields, a quarter of consumers still need one call back for something else.

4. Trade-offs

Broker vs mediator

Broker topology wins on scalability, responsiveness and extensibility; mediator topology wins on workflow control, error handling and seeing where a request is. Many systems use a broker for simple fan-out and a mediator for complex, failure-sensitive workflows.

Thin vs fat events

Thin events keep contracts small but cause callbacks and couple consumers to the producer's API. Fat events avoid callbacks but couple consumers to a larger schema and cost bandwidth. Carry what most consumers need.

Responsiveness vs consistency

Replying as soon as the event is published is fast, but the rest of the system catches up later. Users may briefly see an order without its payment status.

Extensibility vs testability

Adding a consumer needs no producer change, which also means no single place shows the whole flow. Testing needs contract tests per event and end-to-end tests of the main paths.

5. In real projects

The swarm of gnats. Teams new to events often publish one event for every field change: OrderAddressChanged, OrderPhoneChanged, OrderNoteChanged. Consumers subscribe to dozens of tiny events, ordering between them gets hard, and the meaning of a business change is lost. Publish events at the level of business facts (OrderAmended with what changed).

Plan for errors from day one. In broker topology, a failed processor can't ask a coordinator what to do. A common answer is a workflow event pattern: the failing processor publishes the event to an error channel, a separate workflow processor (or a person) repairs it, and resubmits it, while the original processor carries on with other events.

Don't lose events. Use persistent topics, acknowledge only after processing, make consumers idempotent (they will see duplicates), and publish events together with the database change (the transactional outbox, Module 20).

Request/reply still exists. When a caller truly needs an answer, event-driven systems use a reply queue and a correlation ID: the caller waits on its own queue for the reply with its ID.

Say it in the interview

Two-sentence answers
  • "Event vs message?" An event says something happened and goes to anyone interested; a message is a command to one receiver. Events decouple the sender from who reacts.
  • "Broker or mediator topology?" Broker for simple fan-out where extensibility and speed matter; mediator when the workflow has ordered steps and failures that need coordinated handling.
  • "What's an anemic event?" One that carries only an ID, so every consumer calls back for the data. It multiplies load on the producer and couples consumers to its API.
Red flags interviewers notice
  • No answer to "what happens when a consumer fails?"
  • Events named as commands (SendEmail on a topic).
  • Assuming events arrive exactly once and in order.

6. Remember it

Memory hook: "Shout what happened, don't say what to do"Events are past-tense facts broadcast to whoever cares. Commands go to one receiver.
How this hook works: what "shout what happened" means

What the slogan means, phrase by phrase

"Shout"
Publish to a topic, not to a named receiver.
"what happened"
A past-tense business fact: OrderPlaced, PaymentTaken.
"don't say what to do"
The producer doesn't decide who reacts or how; that's what keeps it decoupled.

Why this picture fits: the newsroom works because the reporter announces news instead of assigning tasks; adding a new team never changes the reporter.

The story → the concept

NewsroomEvent-driven system
"Fire at the docks!"Initiating event
Photographer, editor, web teamEvent processors
"Photos are in"Derived event
The news editor directing coverageMediator topology

The trap it saves you from

Building a relay race on a message broker: commands passed along a chain, with all of the coupling and none of the decoupling.

7. Common mistakes

No error strategyA failed consumer in broker topology leaves the workflow half-done and nobody knows. Design error channels, retries and repair before going live.
Anemic eventsID-only events turn every event into N callbacks. Include what most consumers need.
The swarm of gnatsDozens of fine-grained change events instead of meaningful business events.
Assuming order and uniquenessBrokers redeliver and partitions reorder. Consumers must be idempotent and tolerate out-of-order events.

8. Design exercise (30 minutes)

  1. Draw it both ways (15 min). Take an order workflow: place, pay, reserve, ship, notify. Draw it as broker topology with derived events, then as mediator topology.
  2. Break it (10 min). In each drawing, make payment fail. Write exactly what happens to the reserved stock and the customer.
  3. Design one event (5 min). Write the fields of OrderPlaced so that most consumers never need to call back.

9. Self-check quiz

In broker topology, how do you add a new loyalty-points feature that reacts to orders?

That extensibility is the main strength of broker topology.

A workflow has strict ordering and needs coordinated undo on failure. Which topology?

A mediator knows the steps and can compensate when one fails.

What's the main cost of ID-only (anemic) events?

Callbacks multiply load and re-couple consumers to the producer.

Which name is a well-formed event?

Events are past-tense facts; the others are commands.

Brokers can deliver an event twice. What must consumers do?

Processing the same event twice must have the same effect as once.

10. Go deeper

ResourceTimeWhy
What do you mean by "Event-Driven"? (Martin Fowler)20 minFour different things people mean by event-driven, from notification to event sourcing.
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)bookThe event-driven chapter: broker and mediator topologies, error handling, data loss.
Enterprise Integration Patterns (Hohpe and Woolf)browseThe classic catalogue of messaging patterns behind event-driven systems.