The recommendation up front: go point to point until you have three integrations, then put middleware in before the fourth. The threshold is not about complexity, it is about connection count — point-to-point links grow faster than the systems they join, and the migration gets more expensive with every one you add. Below three, middleware is overhead you are paying for a problem you do not have.
The comparison
| Point to point | Middleware | |
|---|---|---|
| Time to first integration | Days | Weeks, including procurement |
| Cost at 1 integration | Developer time only | Licence plus developer time |
| Cost at 10 integrations | Compounding maintenance | Marginal per integration |
| Error handling | Written per integration | Centralised, retries and DLQ |
| Observability | Debug logs, per system | One console across all flows |
| Skills needed | Apex | Apex plus the platform’s own model |
| Failure blast radius | One link | Everything, if the platform is down |
Why connection count is the right metric
Every point-to-point link is a piece of code that has to handle authentication, retries, mapping, error reporting and schema drift. Two systems, one link. Four systems where each talks to two others, and you have several — each with its own version of all five concerns, written by whoever was available that quarter.
The maintenance cost is not linear in the count, because the links interact: a field rename in Salesforce means finding every integration that reads it. With middleware, the mapping lives in one place and the search is a search of one system.
The honest case for point to point
Middleware advocates tend to skip this, and it costs them credibility.
It is dramatically faster to ship. Named Credential, an Apex class, a queueable. Live this week.
It has no additional failure mode. Middleware sits between two systems that were working, and now there are three things that can be down.
Anybody on the team can read it. An Apex class is read by any Salesforce developer. An integration platform’s flow is read by whoever learned that platform, and that person leaves eventually.
It costs nothing extra. Integration platforms are priced per connection, per message, or per core, and at low volume that money buys very little.
For a single nightly sync to one ERP, point to point is not a compromise. It is the right answer, and dressing it up as technical debt is how teams get talked into six-figure platforms for one integration.
What middleware buys that is genuinely hard to hand-roll
Retries with backoff and a dead-letter queue. You can write this in Apex. Doing it well: persisting failed payloads, backing off, replaying selectively, not losing anything on a rollback — is a month of work you will do once per integration.
Transformation between schemas that do not agree. Mapping logic in Apex is code. In a mapping tool it is configuration a business analyst can check. The second is not obviously better, but it is better for the case where the mapping changes often.
Protocol translation. When the far system speaks SOAP, or flat files on SFTP, or a message queue, middleware already does that and Apex does not.
A single place to look when something is wrong. The operational argument, and in my experience the one that actually convinces people after the first bad incident. Tracing a failed order across four point-to-point integrations means four debug logs in three systems.
The platform’s own limits push you toward middleware eventually
Callouts are capped at 100 per transaction with 120 seconds cumulative. API request allocations are per 24 hours and shared across every integration. Heap is 6 MB synchronous, 12 MB asynchronous, so a large payload has to be streamed or chunked.
These are not middleware-specific problems, but middleware absorbs them: it batches, it queues, it holds the large payload outside Salesforce and sends what fits. Hand-rolling the same behaviour is possible and is the work you were trying to avoid.
A middle path worth considering
Platform events give you some of the decoupling without a new vendor. Salesforce publishes an event. Subscribers consume it at their own pace. The publisher does not know who is listening. That handles fan-out and back-pressure reasonably well.
What it does not give you is transformation, protocol translation, or retry semantics across the boundary: a subscriber that fails is a subscriber that failed, and the replay story is yours to build. So this is a real option for fan-out within a Salesforce-centric estate, and not a substitute for an integration platform across a heterogeneous one.
The decision, made concrete
- One or two integrations, stable, same protocol → point to point.
- Three, with a fourth planned → start the middleware conversation now, while the migration is small.
- Any integration where losing a message has financial consequences → middleware, or accept that you are building a durable queue yourself.
- Non-HTTP protocols in the estate → middleware, almost regardless of count.
- No platform skills and no budget for them → point to point, and be honest that you are deferring a cost rather than avoiding one.
Frequently asked
Does MuleSoft being a Salesforce product change the calculation?
It changes procurement and support, not the engineering. The same question applies: how many connections, how much transformation, and who operates it.
Can I start point to point and migrate later?
Yes, and that is the usual path. Make it cheaper by keeping integration logic in dedicated service classes rather than in triggers, so the migration replaces a class rather than unpicking business logic.
Is middleware slower?
It adds a hop, so yes in latency terms. For asynchronous integration that is irrelevant. For a synchronous user-facing call it can matter, and that is an argument for keeping that particular call direct.
What about ETL tools instead?
ETL is for bulk, scheduled data movement. Middleware is for event-driven, message-shaped integration. Many estates need both, and using one for the other’s job is a common and expensive mistake.
How do I justify the cost?
Count the hours spent last year on integration incidents and mapping changes, and the number of integrations planned for next year. If the trend is up and to the right, the case makes itself. If you have two stable integrations, it does not, and you should say so.
Reference: Integration Patterns and Practices, Salesforce Architect resources; Callout Limits and Limitations and Execution Governors and Limits, Salesforce Apex Developer Guide.
