When Event-Driven Integration Is Not the Right Choice: A Practical Follow-Up

In a previous article, I explored how a traditional point-to-point integration can be redesigned using an event-driven architecture, using a shipping notification scenario as an example.

→ From point-to-point integration to event-driven integration: a logistics example

This approach reduces tight coupling, enables scalability, and allows multiple systems to react independently to the same business event.

However, event-driven integration is not always the right solution.

In practice, there are scenarios where introducing a decoupled, event-based design adds more complexity than value.

When synchronous communication is the better choice

Not all integration scenarios are event-driven by nature.

Some processes require immediate feedback and a clear request–response pattern.
The calling system expects a direct answer before it can continue processing.

Typical examples include:

• real-time validation
• availability or consistency checks
• synchronous API calls with immediate business decisions

In these cases, introducing an asynchronous event layer would increase latency and reduce clarity in the overall flow.

A synchronous API-based integration is often the simpler and more appropriate choice.

When strong data consistency is required

Event-driven systems are based on asynchronous communication.

This often leads to eventual consistency rather than immediate consistency.

For scenarios such as:

• financial transactions
• inventory updates
• order confirmations

this behavior can introduce risks if downstream systems expect immediate and consistent data.

When the number of consumers is limited

One of the key advantages of event-driven architecture is its ability to support multiple independent consumers.

However, if a scenario consistently involves only a single consumer — with no realistic expectation of additional consumers — the benefits of an event-driven design are limited.

In such cases, a direct integration pattern often provides:

• lower architectural complexity
• easier monitoring and troubleshooting
• clearer end-to-end data flow

Adding an event broker in these situations can introduce an additional layer without delivering meaningful value.

Operational complexity and overhead

Event-driven architectures introduce additional operational responsibilities that should not be underestimated.

These include:

• event design and versioning
• message ordering considerations
• queue, topic, and subscription management
• monitoring across distributed consumers
• error handling in asynchronous flows

While these capabilities enable scalable and flexible integration landscapes, they require a certain level of operational maturity.

Without clear ownership, governance, and monitoring strategies, event-driven integration can quickly become difficult to manage.

Practical perspective

The key question is not whether event-driven architecture is modern, scalable, or popular.

The real question is:

Does this specific scenario benefit from decoupling?

In many enterprise landscapes, the most effective solution is a hybrid approach, combining different integration patterns based on their strengths:

• APIs for synchronous request–response interactions
• messaging for reliable asynchronous processing
• events for scalable distribution of business facts

SAP Cloud Integration often plays a central role in these hybrid designs, acting as the bridge between APIs, messaging, events, and backend systems.

Conclusion

Event-driven integration is a powerful architectural pattern — but it is not a universal solution.

Knowing when to apply it, and when to deliberately choose a simpler or more synchronous approach, is essential for building maintainable and efficient integration landscapes.

Good architecture is not about using the latest technology everywhere.
It is about choosing the right pattern for the problem at hand.