The Trade-offs of Event-Driven Solutions
Objectives
By the end of the lesson, you can say when an event-driven structure is advantageous, what it costs along the seven aspects, and when it is worth keeping a synchronous call.
Why a separate lesson?
Events are tempting: they look loosely coupled and flexible. Their cost, however, does not appear on the producer's side, but in understanding the system as a whole, in the freshness of data, and in handling repeated, late or out-of-order messages.
When is it strong?
According to the Azure Architecture Center, the event-driven style excels where low-latency, near real-time processing is needed (for example device data, trading systems, large data streams), and gives excellent scalability and fault isolation. Producers and consumers can be developed and scaled independently, and the buffering of the broker can help with transient failures.
What are its costs?
The same description names the delivery guarantee, the ordering of events and eventual consistency across distributed components as challenges.
| Aspect |
Effect |
| Coupling |
Less runtime dependence, but the contract of the event (type, identifier, version, meaning) remains a shared dependency |
| Deployability |
Producer and consumer can be released separately if the schema is compatible |
| Scaling |
Consumers can be scaled separately |
| Data management |
Data copies arise, and looking after them is the consumer's job |
| Consistency |
Eventual consistency; the user may see even their own modification late |
| Failure handling |
Retries, duplicates, late and out-of-order messages (chapter 8) |
| Cost |
Following the flow, observability and debugging are harder |
Traceability
With event notification the whole flow is not visible in one place. An apparently innocent subscription by a new consumer can also create new business feedback. That is why following the flow requires identifiers, observability and a documented event contract (5.2, chapter 8).
The contract of the event
An event should have a stable type, identifier, schema version and business meaning. A timestamp does not guarantee a global order. The data owner should not automatically send its whole internal table at every change: a public event is the contract of cooperation, not a mirror of the internal database. An event can carry the full data (less dependence, bigger schema) or only an identifier (smaller schema, query back, that is, a synchronous dependence).
When should the synchronous call be kept?
When an immediate decision is needed (authorisation, the result of a reservation), a direct answer is natural. Events fit long processing and several independent reactions well. Not every service call has to be replaced by an event, because the price of asynchronous operation is the pending state, the late result and a process tracked in several places (6.2).
flowchart TD
Q{"Does the caller need<br/>an immediate answer?"} -->|"Yes"| S["Synchronous request–response"]
Q -->|"No"| R{"Are several independent<br/>reactions needed?"}
R -->|"Yes"| E["Event"]
R -->|"No"| K["Command, queue"]
Common misconceptions
| Statement |
Clarification |
| "With events the system is automatically loosely coupled." |
The coupling moves into the event contract. |
| "Asynchronous is always faster." |
The result may be late; a pending state appears on the user's side. |
| "Every call must be replaced with an event." |
For immediate decisions the synchronous call is natural. |
In short
- The event-driven structure is strong in real-time processing and with independent consumers.
- Its costs: traceability, schema, eventual consistency, repetition and ordering.
- An event is a contract, not a mirror of the internal data.
- For an immediate decision the synchronous call is natural.
Review questions
- Where does the cost appear in an event-driven structure when the producer's side looks simple?
- When is it better to send full data in the event, and when only an identifier?
- In which situation would you stay with a synchronous call?
Learning resources
The Trade-offs of Event-Driven Solutions
Objectives
By the end of the lesson, you can say when an event-driven structure is advantageous, what it costs along the seven aspects, and when it is worth keeping a synchronous call.
Why a separate lesson?
Events are tempting: they look loosely coupled and flexible. Their cost, however, does not appear on the producer's side, but in understanding the system as a whole, in the freshness of data, and in handling repeated, late or out-of-order messages.
When is it strong?
According to the Azure Architecture Center, the event-driven style excels where low-latency, near real-time processing is needed (for example device data, trading systems, large data streams), and gives excellent scalability and fault isolation. Producers and consumers can be developed and scaled independently, and the buffering of the broker can help with transient failures.
What are its costs?
The same description names the delivery guarantee, the ordering of events and eventual consistency across distributed components as challenges.
Traceability
With event notification the whole flow is not visible in one place. An apparently innocent subscription by a new consumer can also create new business feedback. That is why following the flow requires identifiers, observability and a documented event contract (5.2, chapter 8).
The contract of the event
An event should have a stable type, identifier, schema version and business meaning. A timestamp does not guarantee a global order. The data owner should not automatically send its whole internal table at every change: a public event is the contract of cooperation, not a mirror of the internal database. An event can carry the full data (less dependence, bigger schema) or only an identifier (smaller schema, query back, that is, a synchronous dependence).
When should the synchronous call be kept?
When an immediate decision is needed (authorisation, the result of a reservation), a direct answer is natural. Events fit long processing and several independent reactions well. Not every service call has to be replaced by an event, because the price of asynchronous operation is the pending state, the late result and a process tracked in several places (6.2).
flowchart TD Q{"Does the caller need<br/>an immediate answer?"} -->|"Yes"| S["Synchronous request–response"] Q -->|"No"| R{"Are several independent<br/>reactions needed?"} R -->|"Yes"| E["Event"] R -->|"No"| K["Command, queue"]Common misconceptions
In short
Review questions
Learning resources