Event-driven architecture: brokers, mediators and event streams

Definition: reacting to things that happen

In event-driven architecture (EDA), components communicate by producing and reacting to events: records of facts that have happened in the business, such as an order was placed or a courier was assigned. The component that publishes an event does not call the components that react to it and usually does not know they exist. A message broker carries events from producers to consumers, holds them while consumers are busy or down, and lets new consumers be added without changing the producer.

Event-driven designs are not new: graphical user interfaces, operating systems and trading systems have worked this way for decades, and enterprise messaging products predate the web. What changed in the 2010s was scale and durability. Log-based brokers such as Apache Kafka, created at LinkedIn and open-sourced in 2011, made it practical to keep every business event for days or years and to replay them. EDA can be the main style of a system or, more commonly, the way the services of a microservices or service-based system talk to each other.

Events, commands and messages

Three words are often used loosely, and the difference matters. A message is the envelope: any data sent from one program to another through a channel. What the message carries can be an event (a fact, named in the past tense), a command (a request addressed to one handler, named as an instruction) or a query and its reply. Gregor Hohpe and Bobby Woolf's Enterprise Integration Patterns (2003) catalogued these message types and the channels that carry them, and their vocabulary is still the standard one.

Messages travel through two kinds of channel. A queue delivers each message to one of its consumers, which suits commands and work distribution. A topic delivers a copy of each message to every subscriber, which is publish-subscribe (pub-sub) and suits events. A design that sends OrderPlaced to a topic lets Payments, Restaurant, Notifications and Analytics all react, each in its own time; adding a fraud-detection service next year means one new subscription and no change to Ordering.

Broker topology and mediator topology

Richards and Ford describe two topologies for event-driven systems. In the broker topology there is no central coordinator. An initiating event is published; every interested processor reacts and may publish further events, which others react to in turn. The workflow exists only as the sum of these reactions. This is choreography: like dancers who each know their own steps, no one directs the whole.

In the mediator topology an event mediator receives the initiating event and directs the workflow, sending commands to processors in a defined order and acting on their replies. This is orchestration: a conductor knows the score. Mediators range from a simple service with a state machine to a workflow engine such as Temporal, AWS Step Functions or a BPMN engine.

Most real systems mix both: choreography between bounded contexts (Ordering announces facts and does not care who listens) and orchestration inside a context where a multi-step process needs a clear owner.

Four ways to use events

In a 2017 article Martin Fowler pointed out that 'event-driven' is used for at least four quite different patterns, and that conversations go wrong when people mean different ones. Telling them apart is one of the most useful habits an architect can have.

Event notification and event-carried state transfer are about communication between services and belong in this chapter. Event sourcing and CQRS are about how one service stores its data; they are often combined with EDA but are independent choices, covered in Chapter 7.

Event streams and logs: how Kafka works

Traditional message queues delete a message once a consumer acknowledges it. A log-based broker such as Apache Kafka instead stores events in an append-only log and keeps them for a configured retention period (or for ever) whether or not they have been read. Several things follow from that design, and they explain both Kafka's strengths and its traps.

A topic is split into partitions, each an ordered log stored and replicated across brokers. A producer chooses the partition, normally by hashing the event's key, so all events with the same key (the same order ID, say) go to the same partition. Each event in a partition has a sequential position called its offset. Consumers pull events and record the offset they have reached; they can also rewind and replay.

Consumers join a consumer group. Within one group, each partition is read by exactly one consumer at a time, so the group shares the work; different groups read independently, each with its own offsets, which is how pub-sub is achieved. The number of partitions therefore limits the parallelism of one group: a topic with 12 partitions can keep at most 12 consumers in a group busy. (Kafka 4.2, released in 2026, added share groups as a queue-like alternative: several consumers can share one partition and acknowledge messages individually, but ordering within the partition is then not preserved. This section describes classic consumer groups.)

Kafka guarantees ordering only within a partition. Events for one order arrive in the order they were written if they share a key; events for different orders, in different partitions, have no defined order relative to each other. Designs that need a global order must use a single partition (giving up parallelism) or, better, be redesigned so that only per-entity order matters.

Delivery guarantees, and what 'exactly once' really means

Because networks and processes fail (Section 6.1), a broker and its clients must choose what happens when a crash or timeout leaves it unclear whether a message was processed. There are three possible guarantees, and the choice is made by when acknowledgements and offsets are recorded.

'Exactly once' needs careful definition. Exactly-once delivery over an unreliable network is not achievable in general: a sender that gets no acknowledgement cannot know whether to resend. What systems can provide is exactly-once effect within a defined boundary. Kafka, for example, has offered an idempotent producer and transactions since version 0.11 (2017), so that a read-process-write cycle from Kafka topics to Kafka topics commits its output and its consumer offsets atomically. That guarantee stops at Kafka's edge. If the consumer charges a card, sends an email or writes to another database, a crash between that action and the offset commit will lead to the action being repeated, unless the consumer itself is idempotent or stores its offsets in the same transaction as its results.

The practical rule for architects is therefore simple: assume at-least-once delivery and make every consumer an idempotent consumer. Give each event a unique identifier; in the consumer, record processed identifiers in the same local transaction as the state change, and skip any event already recorded. Where possible, also make the operation naturally idempotent, for example 'set status to PAID if it is AWAITING_PAYMENT' rather than 'add one payment'.

# Idempotent consumer: processing the same event twice has the effect of once
def handle_payment_authorised(event, db):
    with db.transaction():                       # one local ACID transaction
        inserted = db.execute(
            "INSERT INTO processed_events (event_id) VALUES (%s) "
            "ON CONFLICT (event_id) DO NOTHING",
            [event["event_id"]],
        ).rowcount
        if inserted == 0:
            return                               # seen before: do nothing
        db.execute(
            "UPDATE orders SET status = 'PAID' WHERE order_id = %s "
            "AND status = 'AWAITING_PAYMENT'",
            [event["order_id"]],
        )
    # commit the broker offset only after the transaction has committed

Event schemas and versioning

Once other teams consume an event, its structure is a published contract, just like an API, and it lasts longer: with a log-based broker, consumers may read events written months ago. A good event has a unique identifier, a type, a schema version, the time it occurred, the identifiers of the entities involved and the business data consumers need. Money is stored in minor units with a currency, never as a floating-point number (Chapter 0).

{
  "event_id": "9f1c2e7a-4b0d-4e55-9a51-0c3d8f2b6a10",
  "type": "OrderPlaced",
  "schema_version": 2,
  "occurred_at": "2026-10-22T18:42:07Z",
  "order_id": "ord-4711",
  "customer_id": "cus-208",
  "restaurant_id": "res-31",
  "items": [{"dish_id": "d-5", "qty": 2, "price_minor": 1150}],
  "total_minor": 2450,
  "currency": "GBP"
}

Schemas should evolve in backward-compatible ways: add optional fields, never remove or rename fields or change their meaning without a new version, and never reuse a field name for something different. Many teams enforce this with a schema format such as Avro, Protocol Buffers or JSON Schema and a schema registry that rejects incompatible changes at publish time. The CloudEvents specification, a graduated Cloud Native Computing Foundation project, standardises the common envelope attributes such as id, source, type and time. Compatibility modes and migration techniques are covered in schema evolution.

Error handling: retries, poison messages and dead-letter queues

Consumers fail for two very different reasons, and they need different treatment. Transient failures, such as a database that is briefly unavailable or a timeout calling another service, usually succeed on retry; retry a few times with exponential back-off and jitter (increasing, randomised delays) so that a struggling dependency is not overwhelmed. Permanent failures, such as a malformed event or one that violates a business rule, will fail every time. Such a 'poison message' must not block the consumer for ever, which on a partitioned log would stall every later event in that partition.

The standard answer is a dead-letter queue (DLQ): after a set number of attempts the message is moved to a separate channel, with the error recorded, and the consumer moves on. A DLQ is only useful if someone watches it: alert on its size, give a named team ownership, provide tools to inspect, fix and replay messages, and decide in advance what ordering guarantees are lost when a message is replayed late. Some teams add one or more intermediate retry topics with longer delays before the DLQ.

When to use it, and common mistakes

Event-driven architecture fits when many parts of a business must react to the same facts, when work can happen after the user's request returns, when load is bursty and must be smoothed, and when new consumers are expected over time. It fits less well when a user needs an immediate, definitive answer that depends on several services (although a synchronous call for the answer plus events for the follow-up is a common hybrid), or when strong consistency across services is required.