topic Re: Event-driven architecture in Artificial Intelligence Forum

Event-driven architecture

Atul_Joshi85 — Fri, 10 Apr 2026 02:01:50 GMT

We are currently working on moving a couple of backend processes to event-driven architecture using SAP Business Technology Platform.
In our S/4 system, we already have business events being triggered, but we are not fully clear on the best way to structure the consumer side in BTP.

Right now, we are evaluating both Event Mesh and CAP-based subscribers. My confusion is mainly around when to use a lightweight CAP service vs when Event Mesh alone is sufficient for processing.

Has anyone implemented a similar pattern in production where multiple downstream systems consume the same event? How did you avoid duplication and keep it scalable?

Re: Event-driven architecture

VijayKonam — Fri, 10 Apr 2026 14:36:43 GMT

Did you consider Integration Suite iflows for consumers? The Event Mesh queues (which subscribe to the topics) could directly call an iflow endpoint. a CAP app for a consumer feels an overkill to me.

Re: Event-driven architecture

Atul_Joshi85 — Fri, 10 Apr 2026 14:42:34 GMT

Thanks — that makes sense for simple consumption patterns. My challenge is that we have multiple downstream consumers with different processing needs, and I’m not sure iFlows alone can handle routing, filtering, retries, and lightweight enrichment without becoming tightly coupled.

I’m still trying to understand the boundary between:

Event Mesh → iFlow (simple, single-purpose)
Event Mesh → CAP (when logic, orchestration, or multi-consumer coordination is needed)

If you’ve implemented multi-consumer patterns at scale, how did you avoid duplication and keep the architecture maintainable?

Re: Event-driven architecture

dop9 — Sat, 11 Apr 2026 15:33:05 GMT

Hi Atul,

have you looked at Advanced Event Mesh? Seems to tick all the necessary boxes.

Re: Event-driven architecture

Atul_Joshi85 — Mon, 13 Apr 2026 21:16:33 GMT

Thanks for pointing out Advanced Event Mesh — I agree it ticks a lot of boxes on the infrastructure side: multi‑consumer fan‑out, routing, filtering, replay, and hybrid connectivity are much stronger there than with standard Event Mesh.
For me, AEM solves the event backbone problem (distribution, durability, routing at scale), but I still separate that from the consumer boundary, where I need: – business logic and orchestration – enrichment and validation – idempotency and error handling – coordination across multiple downstream systems
In other words, I see AEM as the enterprise event fabric, and CAP/iFlows as domain consumers that sit on top of it.
So my current thinking is: – AEM for large‑scale, multi‑consumer, hybrid event distribution – CAP or iFlows when I need domain logic, composition, or API exposure on top of those events.
Curious how you’ve drawn that boundary in your projects—do you let AEM do as much as possible, or do you still keep a thin application/service layer for domain behavior?

Re: Event-driven architecture

VijayKonam — Mon, 13 Apr 2026 21:25:20 GMT

At the end of the day, AEM or IS are integration layers. Not supposed to carry business logic. Technical look ups, transformation and translation, yes. But building business logic in the integration layer would become a nightmare. What I do not under stand in your usecase is, when you say multi consumer, would you be able to explain, may be with PizzaHut kind of an example or something totally different? The consumers are always expected to applications or instances that would have the functional/business logic built and then take appropriate actions. All you need is transaction postings in various backend system then we are talking integration platform. Just trying to understand the details.

Re: Event-driven architecture

Atul_Joshi85 — Tue, 14 Apr 2026 12:29:39 GMT

Thanks, @VijayKonam — completely agree that AEM and Integration Suite are integration layers and shouldn’t carry business logic. Let me clarify what I meant by “multi‑consumer” because the issue I’m dealing with is a bit complex than simple transaction posting. since I am from Utilities industry, means residential/ industrial / street light/small shops customer.

My scenario is: one business event → multiple downstream behaviors
Think of something like a PizzaHut order event, but with different consumers needing different slices of the same event:

Customer A: updates order status in S/4.
Customer B: triggers a delivery workflow.
Customer C: enriches the event with customer preferences and pushes it to a loyalty engine
Customer sends a real‑time notification to the mobile app
Customer E: stores the raw event for analytics / replay

Every customer has different latency expectations, different retry semantics, and different enrichment needs. Where the boundary question comes in

AEM gives me:

topic hierarchy
fan‑out
filtering
replay
durable queues
hybrid routing

But AEM won't give me:

domain validation
enrichment (e.g., fetch customer tier, fetch delivery SLA)
idempotency rules
compensating logic
orchestration across multiple systems
API exposure for downstream apps
business‑specific error handling

That’s where I’m trying to draw the line between, since this is my problem statement:

AEM = event backbone
CAP/iFlow = domain consumer boundary

The Major architectural question I’m exploring for multi‑consumer patterns at scale, please suggest if you have insight ,do you:

Let AEM do all routing/fan‑out, and keep each consumer (CAP/iFlow) extremely thin?
Introduce a domain‑specific consumer service (e.g., CAP) that performs enrichment + validation before fanning out to other systems?
Use AEM queues directly per consumer, and let each consumer handle its own logic independently?
Use Integration Suite as the “first consumer” and then orchestrate downstream flows?

This is important for me since I’m trying to avoid and client do not want:

duplicated logic across consumers
tight coupling
consumers re‑implementing the same enrichment
brittle retry chains

So I’m willing to understand this is little weird requirement and if anyone approached this boundary in real projects — especially when the same event must drive multiple, heterogeneous downstream actions.

Appreciate suggestion.

Re: Event-driven architecture

VijayKonam — Tue, 14 Apr 2026 12:59:48 GMT

Thanks for the details Atul.

AEM should be your brokering layer. Topics, Queues, Subscriptions and Fanouts. If needed replays as well but I really doubt that is needed for transaction and becomes complex if you need to replay only for few consumers.

SAP-IS could be your consumer for orchestration, enrichment, workflow triggering agent etc. Unless you have a user interaction at UI level (not workflow) I do not see a need for CAP application. These are mainly for UI applications in my mind. You need a strong service layer probably using APIM as the single point of exposure with strong security and other controls implemented. These services should/could be idempotent and take care of that one individual process, operation or transaction etc. Everything should come together.

If you see you have two consumers with same enrichment, the logic should never be duplicated. Instead this one consumer (IS or Service) should do that and then post another message to a topic that broadcasts it to the end consumers.

For data and analytics related consumers where you need to have replay possibility probably they all should work out of a single topic that broadcasts the event or message. This way you do not have to worry about replays. Segregating analytical and transactional consumers is a must in my mind.

This is how I would design my layers and segregate them with specific job duties.

Hope to discuss more if you have any specific use case to go end to end!

Re: Event-driven architecture

Atul_Joshi85 — Wed, 15 Apr 2026 02:41:44 GMT

Thanks, @VijayKonam — that helps. Let me add one more angle from a Utilities perspective because the patterns get tricky at scale.

In Utilities, a single event (billing, meter read, device update, credit action, move‑in/out) usually drives multiple downstream behaviors with different latency, enrichment, and retry needs. That’s where I’m still trying to draw a clean boundary between what AEM should handle vs. what belongs in a consumer service.

AEM gives me the backbone — routing, fan‑out, durability. But I still need a place for shared enrichment (customer tier, SLA, premise attributes), validation, idempotency, and business‑specific error handling. If every consumer re‑implements that, it becomes hard to maintain.

So the open question I’m exploring is:

Do we keep consumers very thin and let each one handle its own logic, or do we introduce a small domain service that does shared enrichment before fanning out to specialized consumers?

If anyone has implemented this in a high‑volume industry (Utilities, Retail, Telco), I’d love to hear how you avoided duplicated logic and kept the consumer side clean.

Re: Event-driven architecture

sissyhae — Wed, 15 Apr 2026 12:29:03 GMT

What is missed here?
every event has a header, attributes and can carry payload? Solace is doing a lot of such complex use cases and AEM is Solace…