A request asks a question and waits for the answer. An event announces a fact and moves on.
Almost every integration decision reduces to that sentence — and almost every hard-to-operate landscape is the result of ignoring it. The patterns are not rivals; they answer different questions. The pain begins when one is bent into doing the other's job.
The pattern is not a technical preference. It is a promise about how two systems will fail together.
Choose request-response when the caller cannot proceed without the answer. Choose an event when the fact matters to more consumers than you can name today.
What each pattern actually promises
A synchronous call couples availability
When system A calls system B and waits, A has silently inherited B's uptime, latency and maintenance windows. One call deep, that is fine. Three hops deep, the weakest system in the chain sets the availability of the whole journey — and nobody agreed to that.
An event decouples time
The producer announces “employee hired”, “order created”, “posting released” — and is finished. Consumers process at their own pace, can be added without touching the producer, and can replay when they recover. The price: nobody is waiting, so nobody knows instantly whether downstream succeeded.
Failure is where the patterns truly differ
A failed call fails loudly, in the caller's face, at the moment of asking — ideal when a human is waiting on the answer. A failed event fails quietly, later, in a queue — ideal when delivery must survive an outage, and dangerous when nobody owns the queue's monitoring.
Choosing on the dimensions that decide it
SAP Integration Suite carries both patterns — Cloud Integration flows and managed APIs on one side, the event mesh capabilities on the other — so the choice can be made per interface rather than per platform.
The estate needs both — deliberately
Real landscapes are mixed: a user checking an employee's bank details needs a synchronous answer; the hire that created that employee should have been an event, because payroll, IT provisioning, access management and analytics all care and none of them should hold up the hiring transaction.
The failure smell is uniformity. An estate where everything is a point-to-point API call has usually recreated the spaghetti it meant to replace — with better logging. An estate where everything is an event has usually discovered that some questions really did need answers.
Name the interaction→Question or fact?→Choose the contract→Design the failure path first
Rules that survive contact with production
- Decide per interaction, not per project. A single process usually contains both a question and several facts.
- Make every consumer idempotent. Retries and replays are a feature of resilient integration, not an anomaly — processing the same message twice must be safe.
- Give every queue an owner. An unmonitored dead-letter queue is an outage with a delay timer.
- Version the contract, not the consumer list. The point of an event is that tomorrow’s consumer costs the producer nothing.
VISCAP perspective
Integration debt is availability debt. Every synchronous hop you add today is an outage you co-sign for later.
When we review a landscape, we read the interface list against one question: who is waiting on whom, and did anyone decide that on purpose? The map of accidental waiting — batch jobs blocking on live calls, UIs blocking on chains of services — is usually the fastest route to both stability and speed.
The question to ask of every new interface
Not “API or event?” first — but “if the other side is down for an hour, what should happen here?” Answer that honestly, and the pattern usually chooses itself.