When "Duplicate Users" Stopped Being a Problem

There was a period in my career when seeing the same business concept appear in multiple systems made me deeply uncomfortable. If I found a User table in one system and another User table somewhere else, my instinct was to assume that something had gone wrong. The same was true for Accounts, Employees, Customers, Sites, and Organizations. Surely there should be a single authoritative service for each of these concepts. If there wasn't, hadn't we duplicated the data? Weren't we creating conflicting sources of truth?

That intuition drove many of my architectural decisions. Whenever a new system was being designed, one of the first questions I would ask was: who owns Users? It felt like the right question, and for a long time I believed it was.

The question that never produced clarity

Over time, though, I began to notice that this question rarely produced the clarity I expected from it. The conversations it starts tend to follow the same shape. Everyone agrees immediately that there should be a single source of truth. Then the disagreement begins over what that source actually owns. One person argues that Users belong to identity, because that's where authentication lives. Another believes they belong to human resources, because that's where people are hired. Someone else insists they belong to the application itself, because that's where permissions are managed. Everyone is talking about the same word, and everyone is reaching a different conclusion.

For a long time I treated those disagreements as a symptom of unclear architecture — something that would resolve once we found the right diagram. Eventually I realized the problem wasn't the architecture.

It was the question.

The assumption hiding inside the question

Asking "who owns Users?" assumes that User is a single business concept. Once I started examining that assumption, it fell apart. An identity provider owns credentials and authentication. A human resources system owns employment information. An access management capability owns roles and permissions. A scheduling capability owns assignments. A messaging platform may own communication preferences. Every one of those systems is dealing with the same person, but they are not responsible for the same business facts.

So I stopped asking which system owned a concept and started asking which business capability was authoritative for each business fact. It sounds like a subtle shift in wording, but it replaces an argument nobody can win with questions that have actual answers. Who is responsible for determining whether someone is employed? Who decides whether they are allowed to authenticate? Who owns the relationship between an employee and a site? Who determines whether a person has completed mandatory training? Each of those questions has a business answer, and those answers naturally define capability boundaries.

Once the boundaries were drawn that way, what had previously felt like duplication looked very different. The same person could legitimately appear in many systems without violating any principle, because each system was authoritative for different facts about them. The data existed in multiple places. The authority never did.

Capabilities first, services second

That realization also changed how I thought about services. I used to treat the service as the primary design unit: decide which service should own a concept, then fit the functionality around it. Now I think about capabilities first. A capability is a cohesive business responsibility together with the facts it is authoritative for. Whether several capabilities end up inside one service or spread across many is a separate decision — an implementation decision. Capability boundaries describe the business. Service boundaries describe the implementation.

Separating the two changed the character of design discussions. They became less about technology and more about responsibility. Instead of arguing over whether there should be a single User service, the conversation could move to which capability was accountable for each business decision — and once those boundaries were understood, the implementation was often surprisingly straightforward. I've written before about how ownership, not duplication, is the thing worth protecting in distributed systems. This was the shift that first took me there.

What the split doesn't solve

I should be honest about what breaking the concept apart doesn't fix. Splitting User into separately owned facts doesn't remove the need to know that those facts describe the same person. Somebody still has to own the correlation — the identifier that ties an employment record, a credential, and a set of permissions to one human being. That is a real capability with real failure modes of its own, and pretending otherwise just moves the ambiguity somewhere less visible. The decomposition relocates that responsibility; it doesn't dissolve it.

The other risk runs in the opposite direction. Fact-level ownership can be taken too far, until every design conversation reopens the full ontology of Customer before anyone can make a decision. The umbrella words survive because they are useful — they let people talk about the business without enumerating every fact underneath. The mistake was never using them.

It was mistaking them for boundaries.

Looking back

I don't think what changed was my understanding of distributed systems. What changed was my understanding of business concepts. Words like User, Account, Customer, or Employee feel like concrete things, but in practice they are umbrellas covering many related capabilities, and treating an umbrella as a single concept creates ambiguity because different people naturally attach different responsibilities to the same word. Breaking those responsibilities apart dissolved the ambiguity — and, just as importantly, gave me a vocabulary for explaining decisions instead of defending intuitions.

I still encounter architectures where the same concepts appear in multiple systems. Unlike earlier in my career, that no longer makes me uneasy. It simply prompts a different question.

Not "why is User duplicated?"

But "which business facts is each of these systems authoritative for?"

I've found that the answer to that question is almost always where architectural clarity begins.