Skip to content

Software Architecture

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.

Distributed Systems Are an Ownership Problem

I've been trying to understand why distributed systems felt so much harder than monoliths when I first started building them.

Not technically. I expected them to be technically harder. What surprised me was how much harder they were to reason about. I'd read about eventual consistency, retries, idempotency, message ordering, and distributed transactions, and none of those ideas were beyond me individually — if someone explained a pattern or a technology, I could usually follow along without much trouble. But when I sat down to design a distributed system myself, something felt different. Two experienced developers could look at exactly the same problem and arrive at completely different architectures. Both could sound reasonable. Both could work. Yet somehow one solution would almost always prove easier to evolve a year later, and for a long time I couldn't explain why.

I thought I just needed to learn more technology. Now I think I was trying to solve the wrong problem.