Choosing Integration Patterns: Point-to-Point, API-Led Connectivity and Event-Driven Design

Explanation

Most landscapes accumulate integration debt because early point-to-point connections (RFC, IDoc, direct database links) are fast to build but expensive to change later. An API strategy exists to prevent this by deciding, up front, which pattern fits which integration category so that the architecture stays maintainable as the number of consumers grows. Point-to-point integration (a single system calling another directly, e.g. an ABAP RFC call or a direct OData consumption without an intermediary layer) is appropriate for low-volume, stable, tightly coupled scenarios where both endpoints are controlled by the same team and change together. It minimizes latency and infrastructure but does not scale organizationally: every new consumer requires a new connection, and every backend change risks breaking multiple callers because there is no contract boundary. API-led connectivity introduces a managed layer (an API gateway or hub, such as capabilities found in SAP Integration Suite's API Management or a third-party gateway) between producers and consumers. This layer typically separates concerns into system APIs (thin wrappers close to source systems), process APIs (compose or orchestrate several system APIs into a business capability) and experience APIs (shaped for a specific consumer, such as a mobile app or portal). The benefit is decoupling: a consumer only depends on the contract published by the gateway, not on the internal implementation of the backend. This is especially valuable in clean core strategies, where S/4HANA Cloud extensibility is intentionally constrained and integration logic should sit in BTP rather than in custom ABAP. Event-driven design (publishing business events, e.g. via SAP Event Mesh or a message broker, and letting consumers react asynchronously) fits scenarios where near-real-time reaction matters more than immediate response, where multiple unrelated consumers need the same signal, or where backend systems should not be blocked waiting for downstream processing. Typical candidates include stock changes, order status updates, or master data changes that trigger downstream recalculations. Event-driven patterns reduce coupling further because producers do not need to know who consumes an event, but they introduce eventual consistency, message ordering and duplicate-delivery concerns that request/response APIs do not have. In practice, an API strategy should classify integration scenarios into three buckets: (1) simple, stable, single-consumer scenarios where lightweight direct integration is acceptable and building an API layer would be over-engineering; (2) multi-consumer, business-capability scenarios where an API-led layer with clear contracts and versioning is justified; and (3) reactive, decoupled, multi-subscriber scenarios where events are the right fit. Architects should document this classification and revisit it periodically, because scenarios that start simple often grow additional consumers and need to be promoted to API-led or event-driven patterns before technical debt accumulates. A common architectural mistake is defaulting to one pattern for everything, either building a heavy API gateway layer for a single internal, stable connection (unnecessary cost and latency) or relying on point-to-point calls for a scenario with five or more consumers (unmanageable coupling). The right approach is to make the pattern decision explicit and reviewable, tied to consumer count, change frequency, coupling tolerance and latency requirements, not to team habit or tooling familiarity.

Code example

# Illustrative classification checklist (not a tool, used in architecture reviews) Scenario: Vendor master replication ECC -> S/4HANA CloudConsumers today: 1 (migration cutover job)Expected consumers in 12 months: possibly 2 (finance reporting, procurement app)Change frequency of source structure: lowLatency tolerance: batch acceptable=> Decision: Start point-to-point via a scheduled interface; re-evaluate for API-led layer if a second consumer with different data shape appears. Scenario: Sales order creation exposed to 3 channel apps (web, mobile, partner portal)Consumers today: 3, each needing different field subsetsChange frequency: backend fields change with S/4HANA upgradesLatency tolerance: synchronous, sub-second=> Decision: API-led connectivity. Publish one system API close to S/4HANA, one process API for order composition, and per-channel experience APIs via the gateway. Scenario: Stock level change needs to trigger recalculation in 4 unrelated planning systemsConsumers: multiple, growing, no direct coupling desiredLatency tolerance: near-real-time, asynchronous acceptable=> Decision: Event-driven. Publish a stock-changed event; each planning system subscribes independently.

Real project scenario

An architect reviewing a landscape found that a single material master change in S/4HANA Cloud triggered six separate outbound RFC-style calls maintained by different teams, each built as point-to-point over two years as new consumers appeared. Every S/4HANA release cycle required regression testing of all six calls even though most consumers only needed a subset of the same data. The remediation plan classified the scenario as clearly multi-consumer and migrated it to a single system API published through SAP Integration Suite's API Management, with consumer-specific experience APIs replacing the direct calls, reducing regression testing surface to one contract instead of six.

Common mistakes

• Choosing a heavy API-led architecture for a single stable internal integration, adding unnecessary latency and operational cost. • Continuing to add point-to-point connections as consumer count grows instead of promoting the scenario to a managed API layer. • Treating event-driven design as a default "modern" choice without accounting for eventual consistency and duplicate-event handling in downstream logic. • Failing to document the pattern decision, so future architects cannot tell why a given integration was built a certain way. • Ignoring latency and consistency requirements when picking between synchronous API calls and asynchronous events.

Best practices

• Classify each integration scenario by consumer count, change frequency and latency tolerance before choosing a pattern. • Reserve API-led connectivity for multi-consumer or business-capability scenarios, not simple stable single connections. • Use event-driven design when consumers should not block producers and when multiple unrelated subscribers need the same signal. • Document pattern decisions and the conditions that would trigger migrating a scenario to a different pattern. • Revisit integration classifications periodically as consumer counts grow, rather than only at initial build time.

Interview angle

Interviewers assess whether a candidate can justify an integration pattern choice using concrete criteria (consumer count, coupling, latency, consistency needs) rather than defaulting to whichever tool the team knows best; a strong answer walks through a real classification decision and what would trigger re-evaluating it.