Data is not a detail. It is the shape of the system.
You can change code quickly.
Data changes are slower. They affect reports, workflows, integrations, and trust.
That’s why data pulls architecture toward it. Like gravity.
If you get data ownership wrong, everything else becomes harder:
- boundaries blur
- deployments coordinate
- changes feel risky
- “small” work turns into migration work
Data ownership is a boundary, not a permission
A clean rule works surprisingly well:
If a part of the system owns the behavior, it owns the data behind it.
Ownership means:
- you decide the schema
- you decide how it evolves
- you protect the invariants
- you are accountable for correctness
It does not mean other parts can’t use the data. It means they shouldn’t depend on your internals to do it.
The shared database trap (why it feels good and ends badly)
A shared database usually starts as a shortcut:
- one join
- one report
- one “quick fix”
Then it becomes the default integration mechanism.
At that point you don’t have modularity. You have shared fate.
The cost shows up later:
- schema changes break unknown consumers
- teams slow down because they must coordinate
- ownership becomes political
- refactoring becomes terrifying because “someone might depend on this column”
A shared database is a contract. Just the worst kind: invisible, brittle, and hard to evolve.
Three safe ways to share data (without sharing tables)
There are only a few reliable approaches. Each has a cost. Pick intentionally.
1) Ask the owner (API queries) Good when you need fresh data and clear semantics. Cost: runtime coupling and latency.
2) Copy what you need (events + local read models) Good when you need autonomy and fast reads. Cost: eventual consistency and operational discipline.
3) Publish a stable dataset (designed for consumption) Good for analytics and reporting. Cost: data pipelines, governance, and careful definition.
The point is not which one is “best.” The point is that the coupling becomes explicit and manageable.
Consistency is a choice, not a default
Teams often assume “correct” means “strong consistency everywhere.”
That’s rarely realistic once you split boundaries.
So you decide:
- where you need strict correctness in the moment
- where “correct soon” is acceptable
- where you can tolerate stale reads
- what users should see during conflicts
This is architecture work.
If you don’t make the choice explicitly, you still get a consistency model. It just arrives as a surprise in production.
Data decisions must be designed for change
Data is long-lived.
That means evolution matters:
- adding fields safely
- deprecating old fields
- migrating without breaking consumers
- rolling changes forward without downtime
A simple habit helps:
Treat schema changes like contract changes. Because they are.
If you make data evolution boring, the whole system becomes calmer.
Closing
Good architecture makes change cheap.
Data ownership is one of the strongest ways to do that.
Keep ownership clear. Avoid invisible coupling. Choose how data flows across boundaries. And evolve schemas like contracts.
That’s how you keep the system modular, even as it grows.
Key takeaways / refresher bullets
- Data creates “gravity.” It shapes architecture more than most code does.
- Ownership rule: own the behavior → own the data.
- Shared databases create invisible contracts and shared fate.
- Share data safely via: API queries, events + local read models, or published datasets.
- Consistency is a design choice: decide where you need strict vs eventual behavior.
- Treat schema evolution like contract evolution: backward-compatible by default.
- Make data change boring, and the system becomes easier to change.