Data Ownership

The Ownership Model

 three roles for any piece of data:

 OWNER:     the ONE service allowed to WRITE it.
            owns schema, lifecycle, quality, migrations.
 CONSUMER:  reads via owner's API or events. never writes.
 REPLICA-HOLDER: stores copies (from events) for local
            reads; refreshes only from the source stream.

 [orders: OWNER of orders]──events──►[analytics: replica]
        ▲ writes ONLY here                reads locally ✓

 ownership ambiguity is where microservices rot:
 two writers → no one owns correctness → drift + blame.

Assigning Ownership

 ownership follows the BOUNDED CONTEXT that defines
 the entity's MEANING:

 - user IDENTITY/profile → identity service
   (not "whoever needs it")
 - order LIFECYCLE → orders
 - stock LEVELS → inventory
 - payment RECORDS → billing

 judgment calls worth pre-deciding:
 □ derived values (order_total): computed by owner,
   stored as fact; consumers never recompute differently
 □ reference data (country list): clear single owner;
   replicated everywhere via versioned snapshots
 □ joint entities (review links user+product):
   review OWNS the review; references others by ID only.

Enforcing Ownership in Practice

 trust but ARCHITECT:

 □ CREDENTIAL SEPARATION: DB users per service with rights
   ONLY to their own schemas — even within shared clusters
 □ NETWORK POLICIES: service A literally cannot reach B's store
 □ API CONTRACTS: everything else goes through documented APIs
 □ EVENT SCHEMAS: replicas built from versioned streams
 □ AUDIT QUERIES: periodic scans for foreign-service access
   patterns (connection metadata tells on violators)

 cultural complement: "why does your ticket require writing
 MY tables?" should start a boundary conversation,
 not a permissions exception.

The Replica Discipline

 holding copies is fine — sloppily is not:

 replica rules:
 □ SOURCE-OF-TRUTH labeled on every table ("replica@orders-events")
 □ IDEMPOTENT projection handlers (redelivery-safe)
 □ STALENESS VISIBLE: watermark per replica monitored
 □ REBUILDABLE: wipe-and-replay must always work
   (it's your bug-recovery and migration path)
 □ NO LOCAL WRITES to replica fields beyond projection logic
   (the moment a consumer mutates its copy, it's divergent fiction)

Violation	Consequence
Consumer writes owned field	silent divergence, blame storms
Missing watermark	invisible staleness bugs
Non-idempotent projection	replay = corruption
Shared credentials	boundaries dissolve quietly

Interview Framing

“Analytics team wants to UPDATE status fields directly in the orders DB for speed” scored response: refuse the write-path violation explicitly, offer alternatives ranked (consume events into THEIR store → they own their copy; propose field addition through contract if truly orders-data), enforcement mechanics named (credentials/network), replica-discipline rules listed. Data ownership questions test whether boundaries exist in your head or just in diagrams.