Event-Driven Architecture: Four Different Meanings
Objectives
By the end of the lesson, you can distinguish the four meanings of the term "event-driven", and recognise which one a concrete design refers to.
Why separate them?
When two people say "they are building an event-driven system", they may easily be talking about two different things. One means that services notify each other; the other that every state change is stored as a sequence of events. The cost and risk of the two solutions differ greatly. Martin Fowler therefore names four separate patterns.
What is an event?
An event is a fact that has happened: "something happened". It is different from a command, which expresses an intention and which the recipient may refuse (discussed in detail in lesson 6.2). The producer does not wait for the consumer and does not even know about it; the Azure Architecture Center also describes it so: producers and consumers communicate through a channel or broker, without direct dependence.
The four meanings
Pattern
What does it mean?
Main advantage
Main risk
Event notification
The system notifies the others about a change in its own domain
Low coupling, easy to introduce
The whole flow is not visible in the code; the event can become a disguised command
Event-carried state transfer
The event carries the changed data, the receiver keeps its own copy
Less dependence on the source, lower latency
Many data copies; the receiver must maintain the state
Event sourcing
Every state change is stored as an event; the event log is the source of truth
Auditability, replay
Schema change; replaying external effects
CQRS (Command Query Responsibility Segregation)
Separate data structure for reading and writing
Handling different read and write needs
Extra complexity; misused pattern
Fowler stresses that CQRS is, strictly speaking, not about events, and can be used without them.
flowchart LR
P["Producer"] -->|"event"| C["Channel"]
C --> F1["Consumer 1"]
C --> F2["Consumer 2"]
Event notification
The producer only reports that something changed, with minimal data. The consumer queries back if needed. This keeps coupling small: the producer does not need to know about the consumers. Fowler warns: the logical flow gets scattered, so it is hard to see, debug and change. It is also a frequent mistake that the "event" is actually a command that the producer expects the receiver to carry out.
Event-carried state transfer
The event also carries the data, so the receiver does not query back but updates its own copy. This improves resilience (there is data even when the source is down) and reduces the load on the source, but it copies data, and the receiver has to look after the state. The freshness of the copy is part of the contract (4.4, 5.1).
How do they relate to each other?
The four patterns can be used independently and can be combined. A system can be based on event notification without event sourcing, and can use CQRS independently of events. The following lessons discuss event sourcing and CQRS, then the common trade-offs.
Common misconceptions
Statement
Clarification
"Event-driven system = event sourcing."
Event sourcing is only one of the meanings.
"Events eliminate coupling."
The connection remains through the contract of the event (4.4).
"An event is a command under a different name."
An event is a fact, a command is an intention; if the event behaves as a command, that is a mistake.
"CQRS requires events."
Not necessarily; it can be used without them.
In short
The four meanings of "event-driven": event notification, event-carried state transfer, event sourcing, CQRS.
An event is a fact, a command is an intention.
Event notification has low coupling, but the flow is scattered.
Event-carried state transfer copies data in return for reducing dependence.
Review questions
Which of the four meanings does not even require events?
What is the difference between an event notification and an event carrying data?
Why is it dangerous when an event actually behaves as a command?
Event-Driven Architecture: Four Different Meanings
Objectives
By the end of the lesson, you can distinguish the four meanings of the term "event-driven", and recognise which one a concrete design refers to.
Why separate them?
When two people say "they are building an event-driven system", they may easily be talking about two different things. One means that services notify each other; the other that every state change is stored as a sequence of events. The cost and risk of the two solutions differ greatly. Martin Fowler therefore names four separate patterns.
What is an event?
An event is a fact that has happened: "something happened". It is different from a command, which expresses an intention and which the recipient may refuse (discussed in detail in lesson 6.2). The producer does not wait for the consumer and does not even know about it; the Azure Architecture Center also describes it so: producers and consumers communicate through a channel or broker, without direct dependence.
The four meanings
Fowler stresses that CQRS is, strictly speaking, not about events, and can be used without them.
Event notification
The producer only reports that something changed, with minimal data. The consumer queries back if needed. This keeps coupling small: the producer does not need to know about the consumers. Fowler warns: the logical flow gets scattered, so it is hard to see, debug and change. It is also a frequent mistake that the "event" is actually a command that the producer expects the receiver to carry out.
Event-carried state transfer
The event also carries the data, so the receiver does not query back but updates its own copy. This improves resilience (there is data even when the source is down) and reduces the load on the source, but it copies data, and the receiver has to look after the state. The freshness of the copy is part of the contract (4.4, 5.1).
How do they relate to each other?
The four patterns can be used independently and can be combined. A system can be based on event notification without event sourcing, and can use CQRS independently of events. The following lessons discuss event sourcing and CQRS, then the common trade-offs.
Common misconceptions
In short
Review questions
Learning resources