---
title: "Federating systems without merging them"
summary: "When several products serve genuinely different audiences, consolidation can destroy what made each one good. Published contracts can do the same job with less loss, at a real operational cost."
canonical: https://cpaas.co/en/learn/federating-without-merging
kind: whitepaper
depth: advanced
origin: original
published: 2026-07-20T16:26:18.899Z
updated: 2026-10-14T16:26:19.548Z
topics: ["Architecture", "CPaaS", "Procurement"]
language: en
---
# Federating systems without merging them

## Why this matters

Most organisations that buy or build communications end up with several systems that overlap: a marketing tool and a support inbox that both send WhatsApp messages, a CRM and a messaging platform that both store contacts, two products from an acquisition that do similar things. The usual instinct is to merge them into one. Sometimes that is right. Often it is expensive and makes both worse. This piece explains the alternative, connecting systems through published interfaces ("federation"), what it requires, what it costs, and a simple test for choosing between the two. It applies equally to a buyer choosing between an all-in-one suite and several specialised tools.

## Why merging can destroy value

Products that serve different audiences differ in ways that look like duplication and are not.

A tool for developers and a tool for non-technical small-business owners may both send WhatsApp messages. Merging them can produce one product that is too complicated for the second audience and too constrained for the first. The "duplication" was the adaptation to each audience.

The general form: **when two systems share a mechanism but not a user, the mechanism is incidental and the user is the essence.** Consolidating on the mechanism risks throwing away the essence.

## Merge, federate, or buy a suite: the trade-offs

| | Merge into one system | Federate (connect via published interfaces) | Buy one all-in-one suite |
|---|---|---|---|
| Fits different user groups | Poorly: one design for all | Well: each keeps its own design | Depends on the suite's breadth |
| Consistency of data | Strong: one database | Needs discipline: one owner per fact | Strong inside the suite |
| Speed of change | Slower: shared releases | Faster: each deploys alone | Set by the vendor's roadmap |
| Operational cost | Lower once done | Higher: network calls, versioning | Lower for you; paid in licence fees |
| Exit and replacement | Hard: everything is entangled | Easier: replace one part at a time | Hard: the whole stack moves together |
| Best when | Same user, same job | Different users, shared customers | Small team, standard needs |

There is no universally right column. The rest of this piece is about doing the middle one well when it is the right choice.

## What federation actually requires

Four things, in this order.

```diagram:steps
# What federation requires, in order
Published contracts | Not shared code
Consistent identity | Who is calling, and on whose behalf
Consistent conventions | Not a shared database
One direction of authority per fact | Exactly one source of truth; the copies may lag
```

**1. Published contracts, not shared code.** Each system exposes a documented interface, such as an OpenAPI description or an event schema (CloudEvents is one open standard for describing events), and consumes others' interfaces. Shared libraries create a coupling with most of the costs of a merge and few of the benefits, because nobody can deploy independently any more.

**2. Consistent identity.** This is the hard one, and the one most federations skip. Systems calling each other need to prove who they are and on whose behalf they act, with an audit trail and a way to revoke access. Without it you get shared secrets in configuration files, which is a merge by other means. See [service-to-service identity](/en/learn/service-to-service-identity).

**3. Consistent conventions, not a shared database.** Agree on how a contact is identified, how timestamps are formatted, how errors are shaped and how webhooks are signed. Do not agree on one schema: that is a merge wearing a different hat.

**4. One direction of authority per fact.** For every piece of data, exactly one system is the source of truth, and the others hold copies that are explicitly allowed to be slightly out of date. Two systems that both believe they own consent state will diverge, and the divergence may be discovered by a regulator.

Federation is not "leave the systems alone". Systems that share nothing are not federated, just separate. Federation is a specific set of published commitments, and the work is in the commitments rather than the code.

```diagram:layers
# What each system publishes, bottom to top
Its own data | Never shared wholesale. Ownership stays where the system is operated and accountable.
A stable identity | Something another system can refer to without knowing how it is stored internally.
A published contract | The interface, versioned, with a deprecation policy. This is the only coupling that exists.
An identity bridge | How a subject in one system corresponds to a subject in another, and who may assert it.
Delegated authority | A scoped, revocable, time-bound grant. One system acting for another, with proof.
Shared evidence | The audit trail spanning the boundary, so a question can be answered across it.
> The bottom layer is what merging destroys. The top three are what merging is usually attempting to buy, and they can often be had without it.
```

## The delegation pattern

A useful shape is often for one system to *delegate* to another rather than duplicate it.

If one product already has issued credentials, a published specification and a signed webhook dispatcher, while another has the strongest model of a particular domain, the answer is not necessarily to move code between them. The first can call the second, rather than reimplementing what the second already does well.

Nothing moves. Both keep their audiences. The capability becomes available through an interface that was already designed to be called.

```diagram:flow
# One system acting for another, safely
Establish the identity | Each system has a verifiable identity of its own. Not a shared secret, not an API key in a config file.
Request a scoped grant | Narrow: this action, this subject, this window. A grant that is broad because narrow was inconvenient is the vulnerability.
Issue with an expiry | Short-lived and renewable beats long-lived and forgotten. The expiry is the safety property.
Act, and carry the proof | Every action taken under delegation records which grant authorised it.
Revoke independently | One system withdrawing a grant must not require the other's cooperation, or it is not revocation.
> Without step five, you have integration rather than federation. The difference only becomes visible on the day you want to disconnect.
```

## What federation costs

It is not free, and being honest about the costs matters:

- **Network calls where a function call would have done**, with the latency and failure modes that implies.
- **Versioning discipline.** A published contract you can change unilaterally is not a contract. Interfaces cannot be changed on a Friday afternoon.
- **Duplicated read models.** Each system holds a projection of others' data, and projections drift.
- **Duplicated effort.** Several systems may each do their own version of something a shared service would do once.
- **Coordination** for anything that genuinely crosses the boundary.

What you buy: no single change takes everything down, each product moves at its own pace, each carries its own regulatory weight, and any one of them can be replaced, sold or retired without unpicking the others.

The trade is deliberate: you accept operational complexity to keep product independence. That is worth it when the products serve different people, and usually not otherwise. For three services that are really one product, federation is overhead with a nicer name.

```diagram:compare
| What it costs | What it buys
Calls | Network calls where a function call would have done | No single change takes everything down
Change | Versioning discipline: no Friday-afternoon contract changes | Each product moves at its own pace
Data | Duplicated read models that drift | Each carries its own regulatory weight
Effort | Duplicated effort, and coordination across the boundary | Any one part can be replaced, sold or retired alone
> Worth it when the products serve different people. For three services that are really one product, it is overhead with a nicer name.
```

## The test

Before merging two systems, ask: **do they have the same user?**

Not the same buyer. Not the same organisation. The same person, doing the same job, on the same day.

If yes, merging is usually right: the separation is costing you. If no, consider federating, and stop measuring the duplication as though it were pure waste.

```diagram:decision
# Before merging two systems
Do they have the same user — the same person, doing the same job, on the same day? | Merging is usually right: the separation is costing you | Consider federating, and stop counting the duplication as pure waste
> Not the same buyer, and not the same organisation.
```

## What to take away

Publish contracts, bridge identity, delegate with scoped and revocable grants, and share evidence across the boundary. Keep each piece of data where it is accountable. Accept some duplication as the price of independent failure and independent change, and check honestly whether you could disconnect one system tomorrow.

## Where to go next

- [The gap nobody fills: service-to-service identity](/en/learn/service-to-service-identity): the identity layer federation depends on.
- [Evaluating a CPaaS contract](/en/learn/evaluating-a-cpaas-contract): the exit and portability clauses that decide whether a vendor is a part you can replace.

## Sources

[^1]: [OpenAPI Specification](https://spec.openapis.org/oas/latest.html) — OpenAPI Initiative
[^2]: [CloudEvents](https://cloudevents.io/) — Cloud Native Computing Foundation
[^3]: [Standard Webhooks](https://www.standardwebhooks.com/) — Standard Webhooks
[^4]: [Bounded Context](https://martinfowler.com/bliki/BoundedContext.html) — martinfowler.com
[^5]: [RFC 8693: OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693) — IETF

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.