Decision
Why connect every outside system in one place?
Because separate connections multiply. Each application ends up holding its own logins, its own retry behaviour and its own idea of what a failed request means — so when something breaks, "where does this talk to them?" has as many answers as you have applications. Connecting in one place trades a slightly slower first connection for a much cheaper twentieth.
The two shapes
Connecting each system separately
- The fastest possible first connection
- Logins held in every application that needs them
- What to do about a failed request, decided again and again
- Fixing a problem starts by finding which application made the call
- Every new application solves problems that were already solved
Connecting in one place
- One place to add a system
- One place logins are held and changed
- What to do about a failed request, decided once
- Fixing a problem starts somewhere known
- Applications ask in their own terms and stay simpler
The cost is not the code
Writing a second direct connection is not expensive. Living with fifteen of them is. The cost arrives as day-to-day drag: an outage where nobody can say which system called what, a password change that takes a week because it lives in four places, a supplier changing one field and breaking three applications that each read it differently.
None of that shows up when you are deciding how to build the first one, which is exactly why the decision is usually made wrong.
When connecting separately is the right call
When there will genuinely only ever be one or two systems, and they are stable. That is a real case and it is worth being honest about it. The mistake is assuming you are in that case when you are early rather than when you are finished.
Questions buyers ask
- Does this add latency?
- One extra hop, yes. In commerce operations the time is almost always spent waiting for the outside system to answer, not on the routing.
- What if the engine is down?
- Then everything outside is unreachable at once. That is the real trade-off, and it belongs in the conversation as an uptime requirement rather than being waved away.