Data ownership
Why each service must own its data — and why shared databases quietly undo microservice independence.
A service boundary without data ownership is a costume. The boxes look independent; the database still couples every release.
Own the write path
The service that enforces an invariant must be the only writer of the data behind that invariant. Other services may read a copy, call an API, or consume an event — they do not update the source tables.
Shared databases create hidden contracts: column meanings, foreign keys, cascade deletes, and “quick joins” that nobody can change safely. Two teams shipping through one schema are one team with extra meetings.
What “own” does not mean
Owning data does not mean never sharing information. It means:
- writes go through the owning service
- reads of another service’s state are deliberate (API, projection, or event-fed store)
- schema evolution is controlled by the owner
A reporting service may keep a read model of payments. That is fine if payment events (or an explicit export) feed it — not if it joins live payment tables.
Integration without shared tables
Prefer these patterns, in rough order of coupling:
- Synchronous API for a needed answer now (keep it narrow).
- Domain events when others need to react or update their own state.
- Read models / projections inside the consumer for query shapes the owner should not serve.
- Replicated reference data only when it is truly read-mostly and versioned.
Avoid “just query their DB for now.” Temporary shared access becomes permanent.
Transactions stop at the boundary
Once data is split, you cannot rely on a single ACID transaction across services. That is not a defect — it is the trade-off. Design for:
- local transactions inside one service
- idempotent handlers for retries
- eventual consistency across services (see consistency and sagas)
If a business rule truly requires atomic updates across two datasets, those datasets likely belong in one service.
Senior checklist
- Who is the single writer for each critical entity?
- Can this service deploy a schema change without coordinating with others?
- Are cross-service reads going through contracts you could version?
If you cannot answer those, the platform is still a monolith — distributed or not.