How work moves between parts of the system, and who waits for whom.
Event-Driven Architecture.
Publish what happened. Let other parts of the system react in their own time.
Change one thing at a time.
The interesting part is usually why it moved.
When fulfillment stops, does order intake have to stop with it?
The producer waits for fulfillment on every synchronous call.
A healthy durable broker is assumed. Production consumers also need duplicate handling, retry limits and dead-letter recovery.
A producer must wait for every downstream consumer, coupling its availability to work it does not own.
A durable queue buffers work for one consumer in this lab. Broader event-driven systems may fan out through pub/sub or retain streams for replay.
Publishing an event decouples the producer from the consumer’s availability, not from the consumer’s expectations. The schema is still a contract, and it is now one nobody is forced to honour synchronously. What you gain in independence you pay for in tracing, ordering and the work of establishing what actually happened.
What this buys, and what it charges you for.
CouplingLower is preferable↓ 54
The producer no longer waits for this consumer, but event contracts still couple them.
ResilienceHigher is preferable↑ 47
A durable broker preserves work while the consumer is unavailable.
ConsistencyHigher is preferable↓ 50
A published fact can take time to reach every consumer’s view.
Operational complexityLower is preferable↑ 51
Delivery retries, backlog, schemas and replay need operational ownership.
Illustrative scores for this scenario, on a 0–100 scale. They express a direction of change, not a benchmark. Your constraints can change the result. Select a quality to explore the reasoning.
+ What improves
- Consumers can process work independently.
- A durable buffer absorbs temporary consumer outages.
± What gets harder
- Acceptance and completion become different events.
- A broker introduces infrastructure and delivery semantics.
- No file contains the business flow. The sequence exists only as a chain of independent reactions, which makes it harder to read, change and debug than a function call.
Where the edges are.
A pattern is only useful once you know where it stops working. These are the boundaries worth knowing before you commit to it.
When it earns its place
- Independent reactions or burst absorption justify asynchronous delivery.
When to leave it out
- A caller needs an immediate, atomic result from a simple operation.
New ways to fail
- Poison messages can block progress.
- Duplicates and reordering require deliberate handling.
Operating the pattern
- Monitor age of oldest message, backlog, retries and dead letters.
- Carry a correlation identifier through every hop. Without one, reconstructing a single business outcome means reading several services’ logs side by side.
The people behind the system
- Events are contracts; version them with their consumers.
Other directions to consider
- Synchronous calls
- Scheduled batch processing
- A local task queue