Federating systems without merging them

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.

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.

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

Four things, in this order.

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.

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.

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.

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.

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.

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.

• The gap nobody fills: service-to-service identity: the identity layer federation depends on.
• Evaluating a CPaaS contract: the exit and portability clauses that decide whether a vendor is a part you can replace.