BTP & Integrationadvanced

BTP Event Mesh Part 5: Delivery Guarantees, Ordering and Idempotent Consumers

Key takeaway

Handle the realities of event delivery: at-least-once semantics, duplicate events, ordering limits, idempotent consumer design with event IDs and business keys, out-of-order handling with version/timestamps, and reconciliation jobs.

Explanation

📌 KEY POINTS
✅ Delivery is at-least-once: the same event can arrive twice.
✅ Idempotent consumers store processed event IDs (or use business keys) and skip duplicates.
✅ Ordering is not guaranteed across consumers or retries — use timestamps/versions to ignore stale events.
✅ Reconciliation jobs catch rare gaps.
⚠️ A consumer that updates S/4 successfully but crashes before acknowledging will get the event again — without idempotency it updates twice.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 4 designed EDA. Now delivery semantics.

━━━━━━━━━━━━━━━━━━━━
▶ 1. AT-LEAST-ONCE

Why duplicates happen.

━━━━━━━━━━━━━━━━━━━━
▶ 2. IDEMPOTENCY

Processed IDs, upserts, business keys.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ORDERING

Timestamps, versions, last-write-wins rules.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ERROR HANDLING

Redelivery, DMQ, alerts.

━━━━━━━━━━━━━━━━━━━━
▶ 5. RECONCILIATION

Periodic compare with source.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Store processed event IDs with expiry.
Add version/timestamp checks.
Replay an event and verify no duplicate effect.

✅ CHECKPOINT: replayed and out-of-order events don't corrupt data.

Code example

ABAP Code

===== IDEMPOTENT CONSUMER (pseudo) =====if (processedIds.contains(event.id)) { ack(); return }record = findByKey(event.data.BusinessPartner)if (record && record.changedAt >= event.time) { ack(); return }   // stale eventupsert(event.data); processedIds.add(event.id, ttl=7d); ack()

Real project scenario

An event consumer updated S/4 successfully, then crashed before acknowledging; the redelivered event created a second note entry. Adding processed-ID checks and upserts made the consumer idempotent.

Common mistakes

Assuming exactly-once.
Blind inserts.
Assuming order.
No reconciliation.
No DMQ.

Best practices

Idempotent consumers.
Upserts.
Version checks.
Reconciliation jobs.
DMQ and alerts.

Interview angle

Questions: "What delivery guarantee does Event Mesh provide?", "How do you build an idempotent consumer?", "How do you handle ordering?"
Strong answer: semantics, idempotency, ordering, errors, reconciliation.

Practice this lesson

Quick check

1. A consumer updated S/4 successfully but crashed before acknowledging; the redelivered event caused a duplicate update. What prevents this?

2. How can a consumer avoid older events overwriting newer data?

3. Which delivery guarantee should consumers assume with Event Mesh queues?

Interview questions

1. A production issue is reported in Event Mesh. What would you check first, and how would you troubleshoot it systematically?

Answer it in your own words first, then compare.

2. A consumer applied the same event twice and older events overwrote newer data. How do you design consumers?