Point-to-point integrations create a spiderweb: every new system needs a direct connection to every system it talks to, and a change on one side ripples through all of them. SAP Event Mesh breaks that pattern. Instead of systems calling each other directly, they publish events — "order created", "invoice paid", "stock updated" — to a central broker, and any interested system subscribes. Producers don't know their consumers, and consumers don't care who produced the event. That's the core of event-driven architecture, and Event Mesh is SAP's managed implementation of it on BTP.
What Event Mesh actually does
At its heart, Event Mesh is a message broker as a service. Applications connect to it and do two things:
Publish — send an event to a topic (a named channel like sales/order/created) or a queue (a point-to-point channel where each message is consumed once).
Subscribe — register interest in a topic or queue and receive events as they arrive, asynchronously. The subscriber processes at its own pace; if it's down, messages wait.
The decoupling is the point. The order system publishes "order created" and moves on. Whether zero or five downstream systems care — a warehouse app, an analytics pipeline, a notification service — the publisher neither knows nor cares. Adding a new consumer means subscribing to the topic, not modifying the publisher.
Key takeaway: Event Mesh decouples applications through events — publishers emit to topics/queues and subscribers consume asynchronously. Producers never need to know their consumers.
Topics vs queues: which to use
Topics implement publish-subscribe: every subscriber gets a copy of each message. Use them for broadcast-style events — "price changed" needs to reach the webshop, the mobile app, and the analytics engine simultaneously.
Queues implement point-to-point: each message is delivered to exactly one consumer. Use them for work distribution — ten "invoice to process" messages spread across three worker instances, each handled once.
A common mistake is using topics for workload and queues for notifications. If exactly-once processing matters, you want a queue. If every interested party must see the event, you want a topic.
Protocols: how applications connect
Event Mesh speaks the standard messaging protocols, so you're not locked into SAP SDKs:
AMQP 1.0 — the workhorse for application-to-application messaging, with acknowledgments and transactions. Most Java, Node.js, and Python apps connect over AMQP.
MQTT — lightweight, designed for IoT scenarios where devices have limited bandwidth and processing power. Sensors and edge devices typically use MQTT.
REST — for simple publish/subscribe over HTTP when a full messaging client is overkill.
JMS — for Java EE applications that already speak JMS.
Because these are open standards, a non-SAP system can publish events that SAP systems consume, and vice versa. The broker doesn't care what technology sits on either end.
Where it fits in the Integration Suite
Event Mesh rarely stands alone. The typical pattern: Cloud Integration iFlows consume events from Event Mesh, transform and route them, then call backend systems — or publish new events back. An "order created" event arrives via Event Mesh, an iFlow enriches it with customer master data from S/4HANA, and publishes an "order enriched" event for the warehouse system.
Event Mesh + API Management is another common pair: synchronous APIs for request-response, events for everything that can happen asynchronously. The rule of thumb — if the caller needs an answer now, use an API; if it just needs something to happen eventually, publish an event.
Quality of service and reliability
Messaging systems offer delivery guarantees, and Event Mesh is no exception:
At-least-once — the default. Messages are redelivered until acknowledged, so consumers must be idempotent (processing the same event twice has the same effect as once). Design your handlers accordingly.
Dead-letter queues — messages that repeatedly fail processing get parked in a dead-letter queue instead of blocking the main queue forever. Monitor these; they're where integration bugs go to hide.
Message TTL — time-to-live settings expire stale events. A "flash sale started" event is worthless an hour later; TTL keeps queues from filling with irrelevant history.
Practical guidance
1. Design your topic hierarchy early — domain/entity/action (e.g. sales/order/created) scales; flat topic names become unmanageable past a dozen integrations.
2. Keep events small and self-describing — include enough context (IDs, timestamps, version) that consumers don't need to call back for basics.
3. Version your event schemas — adding a field is fine; renaming one breaks every subscriber. Treat events like a public API.
4. Plan for duplicates — at-least-once delivery means your consumer will eventually see the same event twice. Idempotency isn't optional.
Event-driven architecture rewards upfront design and punishes ad-hoc topic sprawl. A half-day spent on naming conventions and schema discipline saves weeks of debugging mysterious duplicate-processing bugs later.