All experiments
EXPERIMENT 05 / Communication

Event-Driven Architecture.

Publish what happened. Let other parts of the system react in their own time.

HOW TO READ THIS

Change one thing at a time.
The interesting part is usually why it moved.

Interactive experiment STEP 00
Switching approach resets the experiment

When fulfillment stops, does order intake have to stop with it?

Event-Driven Architecture: Synchronous callsOrder service to Fulfillment, synchronous call. The producer waits for fulfillment on every synchronous call.synchronous callSERVICEOrder service0 submittedSERVICEFulfillment0 completed
serviceOrder service0 submitted→ Fulfillment · synchronous call
serviceFulfillment0 completedReceives work
Baseline systemSynchronous requestDeterministic · step by step
Work submitted0
Queue backlog0
Completed0
Failed requests0
Observation

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.

THE PROBLEM

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.

EVERY DECISION HAS A COST

What this buys, and what it charges you for.

Context, not a scorecard
Without the patternWith the patternILLUSTRATIVE / 0–100
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.
GO A LAYER DEEPER

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