Point-to-Point Integration

Point-to-point integration connects each pair of systems with its own dedicated link, with no intermediary such as a broker, hub or gateway in between. Each link has its own code, data format, protocol, credentials and error handling, chosen by whoever built it. The link can take many forms: a synchronous REST or SOAP call, a CSV dropped into another system's SFTP folder, direct reads from another application's database, a message put on a receiver's private queue, or a vendor SDK embedded in the caller. Each link on its own is simple; the trouble is the unmanaged total, which nobody owns, catalogues or monitors.

Because the first link is the cheapest option available. One project team needs data from another system, writes a client or a file export, and delivers in days, with no shared platform to provision, no integration team to queue behind and no new technology to learn. Debugging is easy too, since there is exactly one hop between sender and receiver. For a small number of systems this is often the right call. The cost appears later, when the same shortcut is repeated by many teams over many years: links multiply, formats and transformations are duplicated, and the landscape becomes a web of hidden dependencies nobody fully understands.

Each direct link couples the two systems along several dimensions. Location coupling: the sender knows the receiver's host or folder, so moving it breaks the sender. Format coupling: the sender produces exactly the receiver's schema, so any schema change ripples to every sender. Protocol coupling: retiring SOAP or SFTP forces rewrites on the other side. Temporal coupling: with synchronous calls, a receiver outage fails the sender's own operation. Semantic coupling: the meaning of codes such as status=3 is duplicated in every integration and drifts. Together these mean a change in one system triggers coordinated changes, testing and releases in several others, which is the real cost.

With direct links, each pair of systems can need its own integration, so n systems can require up to n(n−1)/2 links, which grows quadratically: 10 systems can need 45 links, 20 systems 190 and 50 systems 1,225. If links are one-directional and each has its own mapping, the count is worse still. With a mediator such as a broker, hub or event platform, each system connects once, so the number of connections grows linearly with n: 20 systems need 20. The link count matters because every link brings its own mapping, credentials, monitoring and failure mode, so operational cost and change effort scale with links, not systems.

Because in point-to-point integration the producer sends directly to each consumer, and the consumer was there first with its own interface. ERP wants IDoc XML, billing wants CSV, the shop wants JSON version 2 and marketing still uses version 1, so the producer team ends up writing and maintaining a mapping for every consumer. Every new consumer adds code, testing and release work to a team that gets no benefit from it, and a change to the producer's own model forces updates to every mapping. With publish and subscribe, the producer publishes one owned contract, and each consumer translates into its own model at its own pace, using tolerant readers.

Point-to-point is fine when the number of links stays small and the reasons are explicit. Typical good cases are a genuinely synchronous need with one consumer and a stable contract, such as checkout calling a payment API for an immediate authorisation; two services in the same bounded context owned by one team, who can change both together; and a temporary bridge during migration, time-boxed with a documented exit plan. The condition is that the link is managed: registered in the integration catalogue with an owner, a versioned contract, monitoring and credentials that are rotated. Direct links are not the problem; unmanaged, untracked ones that multiply over time are.

Combine several sources, because no single one sees everything. Distributed tracing with OpenTelemetry gives a service graph of synchronous calls that actually happen. Network flow logs and firewall rules reveal connections from systems without tracing, including legacy ones. Database session audits, such as grouping pg_stat_activity by user and application_name, plus grant reviews, expose other applications reading your tables. Code and configuration searches for host names, client libraries and SFTP paths find batch and file integrations, and the credential inventory shows which technical users and keys exist. Record every finding in a catalogue such as Backstage with an owner and protocol, and keep refreshing it from tracing data.

Incrementally, entity by entity, never with a big-bang rewrite. First discover and catalogue every link with owner, style and criticality. Then prioritise the entities with the most consumers, usually customer, product and order. For each one, the source system publishes a single owned contract, for example a CustomerChanged event on Kafka or an API behind a façade. Migrate consumers one at a time onto that contract, then remove the direct link and revoke its credentials. Track progress with a visible metric such as direct consumers per entity per quarter. Finally, govern new work: cross-domain integrations must use the platform, with exceptions requiring architecture review and an expiry date.