BTP Event Mesh Part 4: Event-Driven Architecture Design on BTP
Design event-driven landscapes: topic hierarchy and naming, notification vs data-carrying events, one queue per consumer, fan-out and decoupling, event versioning, combining events with APIs (event + lookup), and when Advanced Event Mesh fits better.
Explanation
📌 KEY POINTS
✅ Use a clear topic hierarchy (namespace/object/action/version) so subscriptions can use wildcards.
✅ Notification events carry keys; consumers call APIs for details — good for sensitive or large data.
✅ Data-carrying events include the needed fields — good for decoupled, high-volume consumers.
✅ Each consumer gets its own queue so failures don't affect others.
⚠️ Changing event payloads without versioning breaks consumers you may not know about.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 covered reliability. Now architecture.
━━━━━━━━━━━━━━━━━━━━
▶ 1. TOPIC DESIGN
- Hierarchy, versions.
━━━━━━━━━━━━━━━━━━━━
▶ 2. EVENT TYPES
- Notification vs data events.
━━━━━━━━━━━━━━━━━━━━
▶ 3. QUEUES PER CONSUMER
- Isolation and independent scaling.
━━━━━━━━━━━━━━━━━━━━
▶ 4. EVENTS + APIS
- Lookup pattern; authorization.
━━━━━━━━━━━━━━━━━━━━
▶ 5. SCALE & GOVERNANCE
- Advanced Event Mesh; event catalog.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Define topic naming convention.
- Decide notification vs data event per use case.
- Create one queue per consumer.
✅ CHECKPOINT: each consumer receives every relevant event independently.
Code example
===== TOPIC CONVENTION =====acme/sales/v1/SalesOrder/Created | acme/sales/v1/SalesOrder/ChangedSubscriptions: CRM queue → acme/sales/v1/SalesOrder/* | DWH queue → acme/sales/v1/* ===== EVENT TYPES =====Notification: { "SalesOrder": "4711" } → consumer GETs details via API (authorized)Data event: { "SalesOrder": "4711", "Customer": "C1", "Amount": 1200 } → consumer uses data directlyReal project scenario
A sales-order event was sent directly to three consumers via one shared queue; each saw only a third of the events. Creating one queue per consumer with topic subscriptions fixed delivery.
Common mistakes
- Shared queues.
- Unversioned payloads.
- Flat topic names.
- Sensitive data in events.
- No catalog.
Best practices
- Queue per consumer.
- Versioned events.
- Hierarchical topics.
- Notification + lookup when sensitive.
- Event catalog.
Interview angle
Questions: "Notification vs data event?", "Why a queue per consumer?", "How do you version events?"
Strong answer: topics, event types, queue isolation, events+APIs, governance.
Practice this lesson
Quick check
1. Three consumers share one queue and each sees only part of the events. What is the correct design?
2. When subscribing to topics in SAP BTP Event Mesh, which wildcard character is used at the end of a topic pattern to match one or more remaining hierarchical levels?
3. When is a notification event (key only) preferred over a data-carrying event?
Interview questions
1. What are the most important design decisions, trade-offs, and best practices in Event Mesh?
Answer it in your own words first, then compare.
2. Design an event-driven architecture for sales order changes consumed by CRM, data warehouse and a mobile app.
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.