The finding is not the problem
The reflex is to consolidate, and consolidation may well be right, but acting on it immediately means fixing an instance of a problem while leaving the generator of that problem running. Two teams did not each build a notification service out of carelessness. One of four things happened, and which one it was changes the remedy entirely.
They did not know. No catalogue, no forum where anyone would have mentioned it, and the second team searched for thirty seconds and gave up. This is a discovery problem, and consolidating the two services without addressing it just means the third one arrives next year.
They knew and it did not fit. The existing service supported email and the new requirement was SMS with a delivery receipt, and extending it meant a quarter of waiting on another team's roadmap. This is a prioritisation and ownership problem dressed as a technical one.
They knew and could not depend on it. The existing service had no SLO, an unresponsive owner, or a history of breaking consumers. A team that takes a dependency it cannot rely on will be blamed for the resulting outages, so building their own was the rational choice given the incentives.
It genuinely is not the same thing. Two things that both "send notifications" may differ on the axis that matters: transactional delivery with an audit trail is a different problem from bulk marketing sends, and a merged service that does both well is harder than two that each do one.
You cannot tell which of these it is from an architecture diagram. It takes a conversation with both teams, and going in with the conclusion already formed will get you a defensive answer rather than a true one.
Weigh migration against duplication honestly
Consolidation is usually presented as obviously correct because the cost of duplication is visible — two codebases, two on-call rotations, two sets of infrastructure — while the cost of migration is in the future and therefore feels smaller. It is not smaller.
Migration means the losing team rewrites working code that delivers no new user value, absorbs the risk of breaking a production integration, and spends a quarter not doing what they were hired to do. The winning team inherits requirements they did not design for, from a consumer who will now hold them accountable for latency and uptime they never committed to. And someone has to fund the resulting platform team, permanently, because a shared service with no owner degrades to the state that caused the duplication in the first place.
So put numbers on both sides. Two services might cost a few hundred pounds a month of infrastructure and a few days a quarter of duplicated maintenance. If migration is two engineer-quarters, the payback period is years, and the honest conclusion may be to leave it alone.
The three outcomes, and when each is right
Merge when the capability is genuinely shared, the duplication is expensive in something that matters — a compliance surface, a security review, a per-message cost that scales — and there is a credible owner who will fund the survivor. Pick the survivor on migration cost and operational maturity, not on which team argues harder or which codebase is newer.
Keep both, deliberately. This is a legitimate outcome and candidates who cannot say it are usually optimising for tidiness. If the two serve different enough needs, or if migration costs more than the duplication ever will, then write down that the duplication is intentional, record which is for which use case, and stop treating it as debt. Undocumented duplication is a problem; documented duplication is a decision.
Let one wither. Often the cheapest path. Freeze the losing service to security patches only, route all new use cases to the survivor, and let the existing consumers migrate opportunistically when they are touching that code anyway. It takes longer and it means living with two things for a while, but it spreads the cost into work that was happening regardless and avoids a big-bang migration nobody funded.
Fix the generator
Whatever you decide about these two services, the discovery and ownership failure is still there. A service catalogue nobody maintains will not help; what helps is a low-friction place where "I am about to build X" gets seen by people who would know, and a norm that says building a second one is allowed but announcing it is not optional.
The ownership half is harder and matters more. Teams reuse a shared service when depending on it is safer than not — a published SLO, a responsive owner, a contribution path for the feature they need. Where that is absent, duplication is not indiscipline. It is teams correctly reading the incentives you gave them, and no amount of governance will out-argue that.
Duplication is a symptom. Consolidating without asking what produced it buys you one tidy diagram and the same conversation again in a year.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).