Beyond Point-to-Point: Designing Integration Architecture That Scales

Most integration landscapes are not designed. They accumulate. A connection is built to meet an urgent need, then another, and within a few years a CRM may exchange data with a dozen systems through a mix of scripts, scheduled jobs and direct API calls.

Each connection may work on its own. Together they create a landscape that is hard to monitor, hard to secure and slow to change.

Recognize the signs

• Changing one system requires coordinated changes in several others.
• Integration failures are reported by users rather than detected by monitoring.
• Nobody can say with confidence which system holds the correct version of a record.
• Credentials and permissions for integrations are managed inconsistently.

Agree where data is mastered

Before choosing tools, decide which system is the source of truth for each data domain. Customer contact details might be mastered in the CRM, while pricing and inventory are mastered in the ERP. These decisions determine the direction of data flow and simplify every later design choice.

Choose patterns deliberately

Different needs call for different patterns. A request-reply API suits an agent checking an order status. An event-driven pattern suits notifying several systems when a customer changes their details. A scheduled bulk process may be right for nightly financial reconciliation.

Salesforce offers native options for many of these, including REST and Bulk APIs, Platform Events, Change Data Capture and Salesforce Connect. Middleware becomes valuable when you need reusable APIs, complex orchestration or connectivity across many systems. It is a means, not a requirement.

Design for failure and visibility

Every integration will eventually fail, whether from a network issue, an unexpected record or a change in another system. Good architecture assumes this, with retry logic, clear error handling, logging and alerting that reaches the right people.

Govern without slowing down

Lightweight standards for naming, versioning, documentation and security make integrations easier to maintain without adding bureaucracy. The aim is that anyone joining the team can understand what an integration does and who owns it.

Moving from point-to-point connections to a deliberate architecture does not require replacing everything at once. It starts with clear principles and applies them to each new or changed integration.