The Middleware Decision: When You Need an ESB vs Point-to-Point

ESB vs Point-to-Point: Defining the Terms

An Enterprise Service Bus (ESB) is a centralised integration infrastructure through which all system-to-system messages flow. Each system connects to the ESB rather than directly to other systems. The ESB provides message routing, transformation, protocol translation, and orchestration services. Systems communicate with each other indirectly — via the ESB — using a canonical message format that the ESB defines and enforces.

Point-to-point integration connects systems directly to each other without an intermediary. System A calls System B's API directly. Salesforce makes an Apex callout to the ERP's REST endpoint directly. The marketing automation platform pushes leads directly to Salesforce via the API. Each integration is an independent, direct connection.

The fundamental trade-off: point-to-point is simple to implement for small numbers of connections but creates O(n²) complexity as the number of systems grows. With 10 systems, there are up to 90 potential point-to-point connections. An ESB reduces this to O(n) connections — each system connects once to the ESB. But the ESB itself becomes a single point of failure, a governance bottleneck, and a cost centre. The mathematics favour ESB at large scale and disfavour it at small scale.

The Spaghetti Integration Problem

Point-to-point integration creates what architects call "spaghetti" when the number of connections grows without management. In a 15-system enterprise landscape with each system potentially connecting to several others, the integration map becomes a web of connections with no central management, no standard error handling, no shared transformation logic, and no visibility into which systems depend on which. When System A's API changes, nobody knows which of the 12 systems that might call System A are affected.

The spaghetti problem appears at a tipping point — organisations typically notice it when a system change cascades unexpectedly, when a new integration requirement requires understanding the full impact on existing connections, or when a major system replacement (e.g., replacing the ERP) reveals the full scope of direct connections that must be re-implemented. At this point, the argument for centralised integration management becomes compelling.

The architectural signals that point-to-point has become unmanageable: integration changes require impact analysis across 5+ direct connections, there is no central inventory of active integrations, production incidents involving integration failures require investigation of multiple direct connections to isolate the root cause, and data inconsistency between systems is common because there is no canonical data transformation layer enforcing consistency.

When ESB Adds Value vs When It Creates Overhead

An ESB (or modern equivalent — MuleSoft Anypoint, IBM App Connect, TIBCO, WSO2) adds genuine value when: there are more than 5-7 systems with multiple interconnections, message routing logic is complex (the same event must be routed to different consumers based on content or context), protocol translation is required between disparate systems (SOAP to REST, IBM MQ to HTTP, SAP IDOC to JSON), and there is a dedicated integration operations team that owns and maintains the bus.

An ESB creates overhead without value when: it is used as a pass-through for simple REST-to-REST integrations that require no transformation, the integration team does not have ESB skills and must learn the platform under project pressure, the ESB becomes a bottleneck requiring change requests for any integration modification (slowing down integrations that could be done point-to-point in hours), or the organisation does not have the operational maturity to maintain the ESB infrastructure (patching, scaling, monitoring) reliably.

The modern enterprise integration architecture recognises three classes of integration with different appropriate patterns: enterprise-grade cross-system integrations (ERP to CRM, ERP to billing — ESB/MuleSoft appropriate), operational SaaS integrations (Salesforce to marketing automation, Salesforce to collaboration tools — iPaaS/point-to-point appropriate), and internal Salesforce platform integrations (Apex callouts to REST APIs, Platform Events — native Salesforce appropriate). Trying to route all three classes through the same platform creates inefficiency.

The Modern Hybrid: API Gateway + Event Bus + Point-to-Point

The contemporary answer to the ESB vs point-to-point debate is a tiered integration architecture: an API Gateway for synchronous service-to-service calls, an Event Bus for asynchronous event-driven integration, and point-to-point for simple direct integrations that don't need the overhead of either.

The API Gateway (AWS API Gateway, Azure API Management, Apigee) provides centralized authentication, rate limiting, monitoring, and versioning for HTTP/REST APIs without the full weight of an ESB. Systems call the API Gateway, which routes to the appropriate backend — Salesforce, SAP, a microservice. The Gateway provides the observability and security controls of an ESB at a fraction of the operational overhead for REST-based integrations.

The Event Bus (Kafka, AWS EventBridge, Azure Service Bus, or Salesforce Platform Events for Salesforce-internal) handles asynchronous event-driven integration where systems publish events and subscribers consume them without coupling. The event bus provides the decoupling benefit of an ESB's pub/sub model without routing synchronous calls through a central bottleneck. Salesforce's Platform Events naturally extend into this tier for Salesforce-connected event flows.

// Architecture decision matrix: which pattern for which integration
// Synchronous, request-response, REST, low transformation complexity:
//   → Direct Apex callout or API Gateway route
// Synchronous, request-response, complex transformation, legacy protocol:
//   → ESB (MuleSoft) for protocol translation + transformation
// Asynchronous, event notification, Salesforce-originated:
//   → Platform Events (internal) or Pub/Sub API (external)
// Asynchronous, event notification, cross-enterprise:
//   → Kafka / EventBridge event bus
// Batch, high-volume, scheduled:
//   → Bulk API 2.0 (Salesforce target) or ETL pipeline

// The ESB routes none of the above exclusively
// — it routes the complex, multi-protocol, multi-hop cases

Operational Considerations

Centralised integration infrastructure (ESB, API Gateway, Event Bus) requires an operational ownership model that distributed point-to-point integrations do not. With point-to-point, each integration is owned by the team that built it — the Salesforce team owns the Apex callout, the ERP team owns the file feed, the marketing team owns the Workato recipe. When the integration breaks, the owner debugs it.

With an ESB, there is a central infrastructure and a routing layer that sits between the integration owners. When an integration fails, is it the ESB's routing logic, the source system's API, the transformation, or the target system? This diagnostic complexity requires a dedicated integration operations team with access to the ESB's monitoring, logging, and diagnostic tools. The ESB team becomes a dependency for every integration team's incident response.

Define integration ownership models before deploying ESB infrastructure. The "integration platform team" model (a central team owns the ESB infrastructure, individual business teams own the integration logic on the platform) works when the business teams have ESB skills. The "integration Centre of Excellence" model (the CoE team owns and builds all integrations on the ESB) works at smaller scale but becomes a bottleneck as the portfolio grows. Neither model works well if the ownership is unclear — the most common ESB failure is not technical, it is the absence of a clear ownership model for integration operations.