Microservices and data: who owns what when you have many services

Over the past year or two, microservices have moved out of narrow technical circles and into director-level meetings. Breaking large systems into small, independently deployable pieces sounds right. But the conversations about the benefits almost never mention what becomes the central problem in practice: data.

When a monolith is broken apart, a question emerges that most teams have no ready answer for. If an order is created in one service, the customer lives in another, and the warehouse is in a third - who among them is responsible for keeping the data consistent?

Where the problem comes from

In a monolith, everything sits in one database. Transactions are atomic. If something goes wrong, the rollback is complete. That is convenient and familiar.

In the microservices world, each service has its own database - otherwise what independence are we talking about. But this means there is no longer a single transaction spanning multiple services. If one service writes its data and the next one crashes, the system ends up in an intermediate state. Who resolves that, and how?

This is not a hypothetical. This is the first real problem teams hit, a few months after they start splitting things apart.

What "data owner" means in this context

A data owner is the service that is the single source of truth for that data. It alone writes, it alone interprets what the data means. Everyone else either queries it or receives a copy through an event.

This sounds simple until real work begins. Then it turns out:

• several teams believe they should own the customer profile;
• the same fields have different names in different services;
• some data nobody wants to own - and it hangs in no-man's-land between teams;
• for certain facts, no source of truth exists at all.

Technical decomposition without agreement on data ownership simply moves the chaos from one monolith into several microservices.

Three questions worth asking before you start splitting

When I work with teams just entering microservice architecture, I usually ask three things.

First. For each key entity - customer, order, product, payment - is there a designated team and service that owns it? Not "we have access to it", but "we are responsible for its completeness and correctness".

Second. How do other services get data from the owner? Synchronous request (API) or asynchronous event? Both approaches work, but they give different guarantees and require different design.

Third. What happens on disagreement? If data in two services diverges - is that a bug, an acceptable delay, or expected behaviour? The team should have an answer, not a surprised look.

What this changes for a manager

From a director or owner's perspective, all of this looks like implementation detail. But the consequences appear at the product and operational level.

When data ownership boundaries are not defined, teams start duplicating logic in their own services. The same validation check lives in three places, each slightly different. A year later, nobody knows which version is correct.

Reports stop reconciling - because different services returned slightly different data at slightly different times. The answer to "how many active customers do we have" depends on whom you ask.

Integrating new systems slows down - because every new data consumer has to figure out which service to query and in what shape the data will arrive.

A practical starting point

If your company is in the middle of - or planning - a split into microservices, I recommend building a simple table before the work begins: entity - owner - access method. Three columns. It can be incomplete. The act of filling it in will already surface the conversations that need to happen.

The question is not whether to use microservices. The question is whether to bring your existing data disorder into them, or to settle ownership first. The second path is longer at the start and considerably shorter a year later.