System Design (HLD)Data Ownership

Data Ownership in Microservices

LevelAdvanced

Duration90 mins

TopicData Ownership

1 / 5

Single Source of Truth

The Ownership Crisis in Distributed Systems

In a monolithic application, data ownership is rarely a conscious decision. All code shares the same database, and any module can read or write any table. This simplicity—while operationally convenient—hides a fundamental architectural tension that explodes when you move to microservices.

The moment you distribute your system, a critical question emerges: Who owns this data? When two services both read and write to the same customer record, which one is authoritative? When they disagree, who wins? When one service updates the record, how does the other find out?

This isn't an abstract concern. In poorly-designed distributed systems, data ownership ambiguity creates cascading failures, corrupted state, and debugging nightmares that can take weeks to resolve. Senior engineers at companies like Amazon, Netflix, and Google have learned—often painfully—that establishing single source of truth is the foundation upon which all other microservices patterns depend.

What You Will Learn

By the end of this page, you will understand what 'single source of truth' means in microservices, why it's essential for system integrity, how to identify data owners, and the architectural principles that ensure each piece of data has exactly one authoritative source. These concepts form the bedrock of all data management in distributed systems.

What Is Single Source of Truth?

Single Source of Truth (SSOT) is an architectural principle stating that for any piece of data, there must be exactly one service or system that is the authoritative owner of that data. The owner is responsible for:

Creating the data and assigning its identity
Validating all changes against business rules
Storing the canonical, current state
Publishing changes to interested consumers
Enforcing invariants that must always hold

This doesn't mean other services can't have copies of the data—they often must, for performance and autonomy. But those copies are explicitly derivative: they are projections, caches, or local views that are synchronized from the source. When conflicts arise, the source always wins.

The Master-Copy Analogy

Think of SSOT like a master recording in music production. There may be thousands of copies on CDs, streaming services, and personal devices, but when someone asks 'What is the official version of this song?', there's exactly one answer: the master. If the artist re-masters the song, all copies should eventually reflect that change. The same principle applies to data in distributed systems.

The mathematical perspective:

In formal terms, SSOT establishes a partial ordering on truth claims. If service A owns entity X, and services B and C have copies, then:

truth(X) = state_in_A(X)
state_in_B(X) ≤ truth(X)  (B's view may be stale)
state_in_C(X) ≤ truth(X)  (C's view may be stale)

This ordering is crucial because it means conflicts are resolvable. Without SSOT, you face the fundamental problem of distributed consensus: multiple services claim to own truth, leading to split-brain scenarios where the system can't determine which state is correct.

SSOT vs. Distributed Truth: System Behaviors
Scenario	With SSOT	Without SSOT
Two services update same entity	Owner service validates; rejects conflicting update	Both updates may succeed; data corruption
Query returns different values	Source is canonical; copies are stale	No way to determine which is correct
Service failure during write	Owner's state is truth; recovery is deterministic	Unknown what data was actually committed
Business rule enforcement	Single service enforces invariants	Rules may be enforced inconsistently
Audit trail	Single authoritative history	Fragmented, potentially conflicting logs

Why Single Source of Truth Matters

The importance of SSOT becomes viscerally clear when you've debugged a production incident caused by its absence. Understanding these failure modes helps you appreciate why experienced architects insist on ownership clarity.

Consequences of Ownership Ambiguity

•Data Corruption Through Concurrent Writes — Without an owner, two services may update the same record simultaneously. Classic example: Order service sets shipping address while User service updates it. The result is a race condition where the final state depends on timing, not business logic.
•Lost Updates — Service A reads entity X, performs computation, writes back. Meanwhile, Service B does the same. One write overwrites the other. Without ownership, neither service knows to check for conflicts.
•Inconsistent Business Rules — If both the Billing service and the Customer service can update a customer's credit limit, which service's business rules apply? Does a compliance check in one service protect against violations in the other?
•Debugging Nightmares — When data is wrong, where do you look? Without ownership, you must examine logs across every service that touches the entity. Changes may have come from anywhere.
•Recovery Ambiguity — After a system failure, how do you restore correct state? If three services have different versions of an entity, which do you trust? Without SSOT, recovery becomes guesswork.
•Audit Failures — Compliance requires knowing who changed what, when. Without ownership, audit trails are fragmented across services, making it impossible to construct a complete history.

The Real-World Cost

A major e-commerce company discovered that 0.3% of orders had inconsistent state between their Order and Inventory services—neither service 'owned' reservation data. This affected ~50,000 orders per month, requiring manual reconciliation and costing millions in refunds, customer service, and engineering time. Implementing SSOT took 6 months; they estimated the ambiguity cost was $4M/year.

The deeper principle:

SSOT isn't just about avoiding bugs—it's about making the system reasonably understandable. A system where any component can modify any data becomes cognitively intractable. Engineers can't reason about behavior because effects can come from anywhere.

With SSOT, you can draw a clear mental model: 'To understand customer data, I look at the Customer service. Only the Customer service can change it. Other services consume it.' This locality of reasoning is essential for maintaining complex systems over time.

Identifying Data Owners

Determining which service should own which data is one of the most important architectural decisions in microservices design. The answer comes from understanding your domain—the business processes, entities, and rules that your system models.

Principles for Assigning Ownership

•The Creating Service Owns — The service that creates an entity is typically its natural owner. The Order service creates orders; it owns order data. The User service creates user accounts; it owns user data.
•Business Rules Determine Owner — The service that enforces the critical business invariants should own the data. If the Inventory service must enforce 'never oversell', it should own inventory quantities.
•Lifecycle Alignment — The owner should be the service that manages the full lifecycle: creation, updates, and deletion. If different services handle different lifecycle phases, you've likely mis-drawn boundaries.
•Domain Expert Ownership — In Domain-Driven Design terms, the owner is the service within the Bounded Context that is the 'expert' on that entity. The Shipping context is the expert on shipment tracking.
•Write Frequency — If one service writes to an entity 100 times more often than others, it's a strong candidate for ownership. High write frequency suggests core responsibility.
•Consistency Requirements — Data requiring strong consistency should be owned by a single service; attempting to maintain strong consistency across service boundaries is extremely expensive.

The Domain-Driven Design Connection:

Domain-Driven Design (DDD) provides the vocabulary for ownership discussions. Each Bounded Context is a distinct model of a subset of the domain. Within a context, entities have clear definitions and ownership. Between contexts, the same real-world concept may have different representations.

For example, 'Customer' means different things to different contexts:

Sales Context: Leads, opportunities, purchase history
Billing Context: Payment methods, invoices, credit limits
Support Context: Tickets, satisfaction scores, escalations

Each context owns its view of the customer. The Sales service owns sales-related customer data. The Billing service owns billing-related customer data. This isn't duplication—it's acknowledging that these are different models serving different purposes.

Example: E-Commerce Data Ownership Map
Entity	Owner Service	Rationale
User Account	Identity Service	Creates accounts; manages authentication
User Profile	Profile Service	Manages display name, preferences, avatar
Order	Order Service	Creates orders; manages order lifecycle
Inventory Quantity	Inventory Service	Enforces 'never oversell' invariant
Product Catalog	Catalog Service	Manages product information and pricing
Shipment	Shipping Service	Creates shipments; tracks delivery
Payment	Payments Service	Processes payment; manages transaction state
Review	Reviews Service	Manages customer reviews and ratings

Beware Shared Entities

When an entity seems to belong to multiple services equally, you've likely discovered either (a) a missing service that should own it, (b) an entity that should be split into multiple bounded concepts, or (c) a service boundary that's drawn incorrectly. Shared ownership is almost never the right answer.

Architectural Patterns for Single Source of Truth

Establishing SSOT requires more than philosophical agreement—you need concrete architectural patterns that enforce ownership at the system level. Here are the primary patterns used in production systems.

Pattern 1: Private Database Per Service

The foundational pattern for SSOT is that each service has its own private database that no other service can access directly. All data access goes through the service's API.

Enforcement: Other services literally cannot read or write the owner's tables; they have no credentials.
Benefit: Clear ownership; changes to schema don't affect other services; owner controls all access patterns.
Trade-off: Other services must call the API for data, adding latency; no cross-service joins.

This is the default in modern microservices. Sharing databases across services is considered an anti-pattern precisely because it violates SSOT.

Pattern 2: Golden Record Pattern

For entities that must be referenced across many services (like Customer or Product), establish a golden record in the owner service. Other services receive copies through events or APIs but treat their local data as a cache.

Golden Record (Owner):
  - Customer entity in Customer Service database
  - Only Customer Service can write
  - Publishes CustomerUpdated events

Derived Records (Consumers):
  - Order Service has customer_name, customer_email (for display)
  - Shipping Service has customer_address (for shipping)
  - Each maintains their own copy, updated from events
  - Each knows their copy may be stale

The key discipline: consumers never modify their copies based on local logic. All changes flow from the owner.

Pattern 3: Command Routing

When a user action affects data owned by multiple services, route commands to the appropriate owner rather than having one service update another's data.

User Action: 'Update my profile and change my password'

Wrong Approach:
  - Frontend calls Profile Service
  - Profile Service updates profile AND calls Identity Service to change password

Correct Approach:
  - Frontend sends UpdateProfile command to Profile Service
  - Frontend sends ChangePassword command to Identity Service
  - Each service handles its own data

This keeps ownership clear and prevents services from needing write access to each other's domains.

Pattern 4: Event Sourcing with Clear Publishers

In event-sourced systems, ownership is determined by which service publishes events for an entity. Only the Customer service publishes CustomerRegistered, CustomerProfileUpdated, CustomerDeactivated events. Other services subscribe but never publish events about customers.

This creates an auditable, append-only log where ownership is explicit in the event stream.

ownership-enforcement-example
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
// ===================================================
// OWNERSHIP ENFORCEMENT: Customer Service
// ===================================================
// The Customer Service is the SINGLE SOURCE OF TRUTH
// for all customer profile data. It:
//   1. Creates customers (assigns IDs)
//   2. Validates all profile updates
//   3. Publishes events for consumers
// 
// NO OTHER SERVICE should directly modify customer data
// ===================================================
 
interface Customer {
  id: string;
  email: string;
  name: string;
  createdAt: Date;
  updatedAt: Date;
  status: 'active' | 'suspended' | 'deleted';
}
 
interface CustomerCreatedEvent {
  type: 'CustomerCreated';
  customerId: string;
  email: string;
  name: string;
  timestamp: Date;
}
 
interface CustomerUpdatedEvent {
  type: 'CustomerUpdated';
  customerId: string;
  changes: Partial<Pick<Customer, 'email' | 'name'>>;
  timestamp: Date;
}
 
class CustomerService {
  private repository: CustomerRepository;
  private eventPublisher: EventPublisher;
 
  // Only the Customer Service creates customers
  async createCustomer(
    email: string,
    name: string
  ): Promise<Customer> {
    // Validate uniqueness (our responsibility as owner)
    const existing = await this.repository.findByEmail(email);
    if (existing) {
      throw new ConflictError('Email already registered');
    }
 
    // Create with generated ID (we control identity)
    const customer: Customer = {
      id: generateId(),
      email,
      name,
      createdAt: new Date(),
      updatedAt: new Date(),
      status: 'active',
    };
 
    await this.repository.save(customer);
 
    // Publish event for consumers to sync
    await this.eventPublisher.publish<CustomerCreatedEvent>({
      type: 'CustomerCreated',
      customerId: customer.id,
      email: customer.email,
      name: customer.name,
      timestamp: customer.createdAt,
    });
 
    return customer;
  }
 
  // Only the Customer Service updates customers
  async updateCustomer(
    customerId: string,
    updates: Partial<Pick<Customer, 'email' | 'name'>>
  ): Promise<Customer> {
    const customer = await this.repository.findById(customerId);
    if (!customer) {
      throw new NotFoundError('Customer not found');
    }
 
    // Validate business rules (our responsibility)
    if (updates.email) {
      const existing = await this.repository.findByEmail(updates.email);
      if (existing && existing.id !== customerId) {
        throw new ConflictError('Email already in use');
      }
    }
 
    // Apply updates
    Object.assign(customer, updates, { updatedAt: new Date() });
    await this.repository.save(customer);
 
    // Publish change event
    await this.eventPublisher.publish<CustomerUpdatedEvent>({
      type: 'CustomerUpdated',
      customerId: customer.id,
      changes: updates,
      timestamp: customer.updatedAt,
    });
 
    return customer;
  }
}
 
// ===================================================
// CONSUMER SERVICE: Order Service
// ===================================================
// The Order Service CONSUMES customer data but does NOT own it.
// It maintains a local cache updated from CustomerService events.
// ===================================================
 
interface LocalCustomerView {
  customerId: string;
  name: string;  // Cached for order display
  email: string; // Cached for notifications
  lastSyncedAt: Date;
}
 
class OrderServiceCustomerSync {
  private localStore: LocalCustomerViewRepository;
 
  // Handle events from Customer Service
  async handleCustomerCreated(event: CustomerCreatedEvent) {
    await this.localStore.upsert({
      customerId: event.customerId,
      name: event.name,
      email: event.email,
      lastSyncedAt: new Date(),
    });
  }
 
  async handleCustomerUpdated(event: CustomerUpdatedEvent) {
    const existing = await this.localStore.findById(event.customerId);
    if (!existing) return; // We might not have this customer
 
    // Apply only the changes we care about
    if (event.changes.name) existing.name = event.changes.name;
    if (event.changes.email) existing.email = event.changes.email;
    existing.lastSyncedAt = new Date();
 
    await this.localStore.save(existing);
  }
 
  // Note: OrderService NEVER calls CustomerService to update
  // customer data. It only reads its local view.
}

Handling Apparent Exceptions

Real systems occasionally present scenarios that seem to violate SSOT. Understanding these cases helps you maintain ownership discipline while solving practical problems.

Case 1: Reference Data Shared Across Services

Scenario: Country codes, currency codes, tax rates—reference data used everywhere.

Solution: Reference data either:

Lives in a dedicated Reference Data Service that owns it
Is treated as configuration, embedded in each service (acceptable for truly static data)

The key is consistency: either all services source from one place, or changes are managed through deployment, not runtime updates.

Case 2: Composite Entities

Scenario: An 'Order' seems to include shipping address (Shipping domain), payment info (Billing domain), and product details (Catalog domain).

Solution: The Order Service owns the Order entity, which contains:

References (IDs) to entities in other domains
Snapshots of data at order time (e.g., product name at purchase, price at purchase)

The Order Service doesn't own the current state of products or addresses—it owns the order's view of them at the moment of ordering. This is proper SSOT: Order Service owns order data, including what that order looked like when placed.

Case 3: Aggregated Computations

Scenario: A dashboard needs data from five services. Does the Dashboard Service own the computed metrics?

Solution: The Dashboard Service owns its computed aggregates but not the source data. It:

Reads from source services (or their event streams)
Computes aggregates
Owns those aggregates as SSOT for 'dashboard metrics'

This is additive ownership: the Dashboard Service adds new owned data (aggregates) without taking ownership from source services.

Case 4: User-Initiated Cross-Domain Changes

Scenario: User updates their address, which affects both Profile (name, avatar) and Shipping (delivery address) domains.

Solution: Recognize these as two separate entities:

User Profile (owned by Profile Service)
Shipping Address (owned by Shipping Service)

The UI collects both inputs but sends separate commands to each owner. If they must be atomic, consider a saga pattern coordinated by an orchestrator—but each service still owns its data.

The Test for True Ownership

When in doubt, ask: 'If this data is wrong, which team do I call to fix it?' That team's service is the owner. If the answer is 'multiple teams', you have an ownership problem to resolve.

Single Source of Truth and Service Coupling

A common concern with strict SSOT is increased coupling: if every service must call the Customer Service for customer data, doesn't that make Customer Service a bottleneck and single point of failure?

This concern is valid but addressable. SSOT doesn't require synchronous dependencies—it requires clear ownership. Here's how to maintain ownership while reducing operational coupling.

High-Coupling SSOT (Avoid)

•Every service calls Customer API synchronously
•Customer Service downtime blocks all operations
•Latency accumulates across service calls
•Customer Service must scale to handle all traffic
•Network failures cause cascading failures
•Tight runtime coupling despite separate deployments

Low-Coupling SSOT (Prefer)

•Services maintain local views updated via events
•Customer Service downtime doesn't block operations
•Local reads are fast; eventual consistency
•Owned service scales for write load only
•Services operate independently during partitions
•Loose runtime coupling; clear ownership

The key insight: SSOT is about write authority, not read availability. The Customer Service is the only service that can change customer data, but other services can read their own locally-cached copies.

This separation allows:

Write operations go to the owner (who validates and persists)
Read operations use local caches (fast and available)
Synchronization happens asynchronously via events
Staleness is explicit and bounded by sync frequency

Eventual Consistency is Usually Fine

Most business processes tolerate slight staleness. If a customer updates their name, it's acceptable if their next order (placed 100ms later) shows the old name. What's not acceptable is permanent inconsistency or data corruption—which SSOT prevents.

Organizational Alignment with Data Ownership

Conway's Law states that system architectures mirror organizational structures. This applies powerfully to data ownership: services should be owned by teams, and those teams should own the corresponding data domains.

Misalignment between team structure and data ownership creates constant friction:

Team A owns Customer Service code but Team B 'owns' customer requirements
Changes require cross-team coordination
Accountability is unclear when issues arise
Decision-making is slow and contentious

Alignment principles:

One team, one service, one domain — The team that owns the Customer Service also owns customer data and customer business logic. They are the experts; they make decisions.
API contracts as team interfaces — Teams interact through service APIs, just as services do. Changing a service contract is a negotiation between teams.
Domain expertise concentrates — Over time, the Customer team becomes the organization's expert on customer data. Other teams defer to their judgment on customer-related questions.
Ownership includes on-call — The owning team is responsible when customer data has issues. This accountability reinforces careful stewardship.

Aligning Teams with Data Ownership
Aspect	Aligned	Misaligned
Who adds customer fields?	Customer team	Any team that 'needs' it
Who validates customer rules?	Customer team	Caller's responsibility
Who pages when data is wrong?	Customer team	Whoever noticed
Who decides customer data retention?	Customer team + compliance	Unknown or assumed
Who reviews customer data access?	Customer team	Security team (without context)

Technical Decisions Follow Organizational Ones

If your organization can't agree on which team owns customer data, your services won't be able to agree either. Resolving ownership is first an organizational conversation, then a technical implementation.

Summary: The Foundation of Data Ownership

Single Source of Truth is the foundational principle for managing data in distributed systems. Without it, systems devolve into chaos—data corruption, inconsistent enforcement, and impossible debugging. With it, you have clear ownership, deterministic behavior, and teams that understand their responsibilities.

Key Takeaways

•Every piece of data needs exactly one owner — The owner creates, validates, persists, and publishes. Copies exist but are explicitly derivative.
•Ownership is determined by domain analysis — Who creates it? Who enforces invariants? Who manages the lifecycle? These questions identify the owner.
•Private databases enforce ownership — No direct access between services; all interaction through APIs and events.
•SSOT doesn't require synchronous coupling — Use event-driven synchronization for reads; reserve synchronous calls for writes to the owner.
•Organizational structure must align — Team ownership and data ownership should match. Misalignment creates friction and unclear accountability.
•Apparent exceptions have solutions — Reference data, composite entities, and aggregations all fit within SSOT with proper modeling.

What's next:

With single source of truth established, we next address a practical reality: data duplication. Even with clear ownership, services often need copies of data for performance and autonomy. The next page explores the trade-offs of data duplication, when it's appropriate, and how to manage it without violating ownership principles.

Page Complete

You now understand Single Source of Truth—the foundational principle of data ownership in microservices. Every data entity needs exactly one authoritative owner, and this ownership drives system clarity, maintainability, and correctness. Next, we'll explore how to manage the inevitable duplication that arises when services need local copies of owned data.

1 / 5

Loading learning content...

System Design (HLD)Data Ownership

Data Ownership in Microservices

LevelAdvanced

Duration90 mins

TopicData Ownership

1 / 5

Single Source of Truth

The Ownership Crisis in Distributed Systems

What You Will Learn

What Is Single Source of Truth?

Creating the data and assigning its identity
Validating all changes against business rules
Storing the canonical, current state
Publishing changes to interested consumers
Enforcing invariants that must always hold

The Master-Copy Analogy

The mathematical perspective:

In formal terms, SSOT establishes a partial ordering on truth claims. If service A owns entity X, and services B and C have copies, then:

truth(X) = state_in_A(X)
state_in_B(X) ≤ truth(X)  (B's view may be stale)
state_in_C(X) ≤ truth(X)  (C's view may be stale)

SSOT vs. Distributed Truth: System Behaviors
Scenario	With SSOT	Without SSOT
Two services update same entity	Owner service validates; rejects conflicting update	Both updates may succeed; data corruption
Query returns different values	Source is canonical; copies are stale	No way to determine which is correct
Service failure during write	Owner's state is truth; recovery is deterministic	Unknown what data was actually committed
Business rule enforcement	Single service enforces invariants	Rules may be enforced inconsistently
Audit trail	Single authoritative history	Fragmented, potentially conflicting logs

Why Single Source of Truth Matters

Consequences of Ownership Ambiguity

•Data Corruption Through Concurrent Writes — Without an owner, two services may update the same record simultaneously. Classic example: Order service sets shipping address while User service updates it. The result is a race condition where the final state depends on timing, not business logic.
•Lost Updates — Service A reads entity X, performs computation, writes back. Meanwhile, Service B does the same. One write overwrites the other. Without ownership, neither service knows to check for conflicts.
•Inconsistent Business Rules — If both the Billing service and the Customer service can update a customer's credit limit, which service's business rules apply? Does a compliance check in one service protect against violations in the other?
•Debugging Nightmares — When data is wrong, where do you look? Without ownership, you must examine logs across every service that touches the entity. Changes may have come from anywhere.
•Recovery Ambiguity — After a system failure, how do you restore correct state? If three services have different versions of an entity, which do you trust? Without SSOT, recovery becomes guesswork.
•Audit Failures — Compliance requires knowing who changed what, when. Without ownership, audit trails are fragmented across services, making it impossible to construct a complete history.

The Real-World Cost

The deeper principle:

Identifying Data Owners

Principles for Assigning Ownership

•The Creating Service Owns — The service that creates an entity is typically its natural owner. The Order service creates orders; it owns order data. The User service creates user accounts; it owns user data.
•Business Rules Determine Owner — The service that enforces the critical business invariants should own the data. If the Inventory service must enforce 'never oversell', it should own inventory quantities.
•Lifecycle Alignment — The owner should be the service that manages the full lifecycle: creation, updates, and deletion. If different services handle different lifecycle phases, you've likely mis-drawn boundaries.
•Domain Expert Ownership — In Domain-Driven Design terms, the owner is the service within the Bounded Context that is the 'expert' on that entity. The Shipping context is the expert on shipment tracking.
•Write Frequency — If one service writes to an entity 100 times more often than others, it's a strong candidate for ownership. High write frequency suggests core responsibility.
•Consistency Requirements — Data requiring strong consistency should be owned by a single service; attempting to maintain strong consistency across service boundaries is extremely expensive.

The Domain-Driven Design Connection:

For example, 'Customer' means different things to different contexts:

Sales Context: Leads, opportunities, purchase history
Billing Context: Payment methods, invoices, credit limits
Support Context: Tickets, satisfaction scores, escalations

Example: E-Commerce Data Ownership Map
Entity	Owner Service	Rationale
User Account	Identity Service	Creates accounts; manages authentication
User Profile	Profile Service	Manages display name, preferences, avatar
Order	Order Service	Creates orders; manages order lifecycle
Inventory Quantity	Inventory Service	Enforces 'never oversell' invariant
Product Catalog	Catalog Service	Manages product information and pricing
Shipment	Shipping Service	Creates shipments; tracks delivery
Payment	Payments Service	Processes payment; manages transaction state
Review	Reviews Service	Manages customer reviews and ratings

Beware Shared Entities

Architectural Patterns for Single Source of Truth

Pattern 1: Private Database Per Service

The foundational pattern for SSOT is that each service has its own private database that no other service can access directly. All data access goes through the service's API.

Enforcement: Other services literally cannot read or write the owner's tables; they have no credentials.
Benefit: Clear ownership; changes to schema don't affect other services; owner controls all access patterns.
Trade-off: Other services must call the API for data, adding latency; no cross-service joins.

This is the default in modern microservices. Sharing databases across services is considered an anti-pattern precisely because it violates SSOT.

Pattern 2: Golden Record Pattern

Golden Record (Owner):
  - Customer entity in Customer Service database
  - Only Customer Service can write
  - Publishes CustomerUpdated events

Derived Records (Consumers):
  - Order Service has customer_name, customer_email (for display)
  - Shipping Service has customer_address (for shipping)
  - Each maintains their own copy, updated from events
  - Each knows their copy may be stale

The key discipline: consumers never modify their copies based on local logic. All changes flow from the owner.

Pattern 3: Command Routing

When a user action affects data owned by multiple services, route commands to the appropriate owner rather than having one service update another's data.

User Action: 'Update my profile and change my password'

Wrong Approach:
  - Frontend calls Profile Service
  - Profile Service updates profile AND calls Identity Service to change password

Correct Approach:
  - Frontend sends UpdateProfile command to Profile Service
  - Frontend sends ChangePassword command to Identity Service
  - Each service handles its own data

This keeps ownership clear and prevents services from needing write access to each other's domains.

Pattern 4: Event Sourcing with Clear Publishers

This creates an auditable, append-only log where ownership is explicit in the event stream.

ownership-enforcement-example
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
// ===================================================
// OWNERSHIP ENFORCEMENT: Customer Service
// ===================================================
// The Customer Service is the SINGLE SOURCE OF TRUTH
// for all customer profile data. It:
//   1. Creates customers (assigns IDs)
//   2. Validates all profile updates
//   3. Publishes events for consumers
// 
// NO OTHER SERVICE should directly modify customer data
// ===================================================
 
interface Customer {
  id: string;
  email: string;
  name: string;
  createdAt: Date;
  updatedAt: Date;
  status: 'active' | 'suspended' | 'deleted';
}
 
interface CustomerCreatedEvent {
  type: 'CustomerCreated';
  customerId: string;
  email: string;
  name: string;
  timestamp: Date;
}
 
interface CustomerUpdatedEvent {
  type: 'CustomerUpdated';
  customerId: string;
  changes: Partial<Pick<Customer, 'email' | 'name'>>;
  timestamp: Date;
}
 
class CustomerService {
  private repository: CustomerRepository;
  private eventPublisher: EventPublisher;
 
  // Only the Customer Service creates customers
  async createCustomer(
    email: string,
    name: string
  ): Promise<Customer> {
    // Validate uniqueness (our responsibility as owner)
    const existing = await this.repository.findByEmail(email);
    if (existing) {
      throw new ConflictError('Email already registered');
    }
 
    // Create with generated ID (we control identity)
    const customer: Customer = {
      id: generateId(),
      email,
      name,
      createdAt: new Date(),
      updatedAt: new Date(),
      status: 'active',
    };
 
    await this.repository.save(customer);
 
    // Publish event for consumers to sync
    await this.eventPublisher.publish<CustomerCreatedEvent>({
      type: 'CustomerCreated',
      customerId: customer.id,
      email: customer.email,
      name: customer.name,
      timestamp: customer.createdAt,
    });
 
    return customer;
  }
 
  // Only the Customer Service updates customers
  async updateCustomer(
    customerId: string,
    updates: Partial<Pick<Customer, 'email' | 'name'>>
  ): Promise<Customer> {
    const customer = await this.repository.findById(customerId);
    if (!customer) {
      throw new NotFoundError('Customer not found');
    }
 
    // Validate business rules (our responsibility)
    if (updates.email) {
      const existing = await this.repository.findByEmail(updates.email);
      if (existing && existing.id !== customerId) {
        throw new ConflictError('Email already in use');
      }
    }
 
    // Apply updates
    Object.assign(customer, updates, { updatedAt: new Date() });
    await this.repository.save(customer);
 
    // Publish change event
    await this.eventPublisher.publish<CustomerUpdatedEvent>({
      type: 'CustomerUpdated',
      customerId: customer.id,
      changes: updates,
      timestamp: customer.updatedAt,
    });
 
    return customer;
  }
}
 
// ===================================================
// CONSUMER SERVICE: Order Service
// ===================================================
// The Order Service CONSUMES customer data but does NOT own it.
// It maintains a local cache updated from CustomerService events.
// ===================================================
 
interface LocalCustomerView {
  customerId: string;
  name: string;  // Cached for order display
  email: string; // Cached for notifications
  lastSyncedAt: Date;
}
 
class OrderServiceCustomerSync {
  private localStore: LocalCustomerViewRepository;
 
  // Handle events from Customer Service
  async handleCustomerCreated(event: CustomerCreatedEvent) {
    await this.localStore.upsert({
      customerId: event.customerId,
      name: event.name,
      email: event.email,
      lastSyncedAt: new Date(),
    });
  }
 
  async handleCustomerUpdated(event: CustomerUpdatedEvent) {
    const existing = await this.localStore.findById(event.customerId);
    if (!existing) return; // We might not have this customer
 
    // Apply only the changes we care about
    if (event.changes.name) existing.name = event.changes.name;
    if (event.changes.email) existing.email = event.changes.email;
    existing.lastSyncedAt = new Date();
 
    await this.localStore.save(existing);
  }
 
  // Note: OrderService NEVER calls CustomerService to update
  // customer data. It only reads its local view.
}

Handling Apparent Exceptions

Real systems occasionally present scenarios that seem to violate SSOT. Understanding these cases helps you maintain ownership discipline while solving practical problems.

Case 1: Reference Data Shared Across Services

Scenario: Country codes, currency codes, tax rates—reference data used everywhere.

Solution: Reference data either:

Lives in a dedicated Reference Data Service that owns it
Is treated as configuration, embedded in each service (acceptable for truly static data)

The key is consistency: either all services source from one place, or changes are managed through deployment, not runtime updates.

Case 2: Composite Entities

Scenario: An 'Order' seems to include shipping address (Shipping domain), payment info (Billing domain), and product details (Catalog domain).

Solution: The Order Service owns the Order entity, which contains:

References (IDs) to entities in other domains
Snapshots of data at order time (e.g., product name at purchase, price at purchase)

Case 3: Aggregated Computations

Scenario: A dashboard needs data from five services. Does the Dashboard Service own the computed metrics?

Solution: The Dashboard Service owns its computed aggregates but not the source data. It:

Reads from source services (or their event streams)
Computes aggregates
Owns those aggregates as SSOT for 'dashboard metrics'

This is additive ownership: the Dashboard Service adds new owned data (aggregates) without taking ownership from source services.

Case 4: User-Initiated Cross-Domain Changes

Scenario: User updates their address, which affects both Profile (name, avatar) and Shipping (delivery address) domains.

Solution: Recognize these as two separate entities:

User Profile (owned by Profile Service)
Shipping Address (owned by Shipping Service)

The UI collects both inputs but sends separate commands to each owner. If they must be atomic, consider a saga pattern coordinated by an orchestrator—but each service still owns its data.

The Test for True Ownership

When in doubt, ask: 'If this data is wrong, which team do I call to fix it?' That team's service is the owner. If the answer is 'multiple teams', you have an ownership problem to resolve.

Single Source of Truth and Service Coupling

This concern is valid but addressable. SSOT doesn't require synchronous dependencies—it requires clear ownership. Here's how to maintain ownership while reducing operational coupling.

High-Coupling SSOT (Avoid)

•Every service calls Customer API synchronously
•Customer Service downtime blocks all operations
•Latency accumulates across service calls
•Customer Service must scale to handle all traffic
•Network failures cause cascading failures
•Tight runtime coupling despite separate deployments

Low-Coupling SSOT (Prefer)

•Services maintain local views updated via events
•Customer Service downtime doesn't block operations
•Local reads are fast; eventual consistency
•Owned service scales for write load only
•Services operate independently during partitions
•Loose runtime coupling; clear ownership

This separation allows:

Write operations go to the owner (who validates and persists)
Read operations use local caches (fast and available)
Synchronization happens asynchronously via events
Staleness is explicit and bounded by sync frequency

Eventual Consistency is Usually Fine

Organizational Alignment with Data Ownership

Misalignment between team structure and data ownership creates constant friction:

Team A owns Customer Service code but Team B 'owns' customer requirements
Changes require cross-team coordination
Accountability is unclear when issues arise
Decision-making is slow and contentious

Alignment principles:

One team, one service, one domain — The team that owns the Customer Service also owns customer data and customer business logic. They are the experts; they make decisions.
API contracts as team interfaces — Teams interact through service APIs, just as services do. Changing a service contract is a negotiation between teams.
Domain expertise concentrates — Over time, the Customer team becomes the organization's expert on customer data. Other teams defer to their judgment on customer-related questions.
Ownership includes on-call — The owning team is responsible when customer data has issues. This accountability reinforces careful stewardship.

Aligning Teams with Data Ownership
Aspect	Aligned	Misaligned
Who adds customer fields?	Customer team	Any team that 'needs' it
Who validates customer rules?	Customer team	Caller's responsibility
Who pages when data is wrong?	Customer team	Whoever noticed
Who decides customer data retention?	Customer team + compliance	Unknown or assumed
Who reviews customer data access?	Customer team	Security team (without context)

Technical Decisions Follow Organizational Ones

Summary: The Foundation of Data Ownership

Key Takeaways

•Every piece of data needs exactly one owner — The owner creates, validates, persists, and publishes. Copies exist but are explicitly derivative.
•Ownership is determined by domain analysis — Who creates it? Who enforces invariants? Who manages the lifecycle? These questions identify the owner.
•Private databases enforce ownership — No direct access between services; all interaction through APIs and events.
•SSOT doesn't require synchronous coupling — Use event-driven synchronization for reads; reserve synchronous calls for writes to the owner.
•Organizational structure must align — Team ownership and data ownership should match. Misalignment creates friction and unclear accountability.
•Apparent exceptions have solutions — Reference data, composite entities, and aggregations all fit within SSOT with proper modeling.

What's next:

Page Complete

1 / 5