Skip to content

ADR-0003: Define Service Data Ownership and Tenant Data Isolation

  • Status: Accepted
  • Date: 2026-10-06
  • Decision Owners: Zelvoryqa Architecture
  • Technical Area: Data Architecture / Multi-Tenancy
  • Related ADRs:
  • ADR-0001: Adopt Microservices Based on Business Capabilities
  • ADR-0002: Adopt Multi-Tenant SaaS Architecture

Context

Zelvoryqa is designed as a multi-tenant SaaS platform composed of independently deployable services aligned to business capabilities.

ADR-0001 establishes that services own their business capabilities, including the operational data associated with those capabilities.

ADR-0002 establishes that one organization corresponds to one logical tenant boundary and that organization-owned operations must execute within validated organization context.

These decisions create two distinct dimensions of data ownership:

  1. Service ownership determines which service is authoritative for a type of operational data.
  2. Organization ownership determines which organization owns a particular organization-scoped resource or record.

For example, the Order Service is authoritative for order operational data across Zelvoryqa, while individual orders belong to specific organizations.

Conceptually:

Order Service
     |
     v
Order Operational Data
     |
     +---- Order 1001 ---> Organization A
     +---- Order 1002 ---> Organization A
     +---- Order 2001 ---> Organization B

Organization ownership does not imply ownership of the service or its underlying infrastructure. A shared Order Service may serve many organizations while remaining responsible for enforcing isolation between their data.

Without explicit data ownership and tenant-isolation rules, a distributed multi-tenant architecture can introduce:

  • Shared database coupling between services
  • Direct access to another service's internal data
  • Ambiguous sources of truth
  • Cross-tenant data exposure
  • Inconsistent tenant filtering
  • Unsafe background or asynchronous processing
  • Cache or analytical data leakage
  • Difficult service evolution
  • Difficult independent deployment
  • Unclear backup, restoration, and migration boundaries

Zelvoryqa therefore requires explicit rules for both service data ownership and tenant data isolation before substantial business data models and persistence implementations are introduced.

Decision

Zelvoryqa will use service-owned operational data with mandatory tenant isolation for organization-owned resources.

Each business service is authoritative for the operational data belonging to its business capability.

Organization-owned data managed by a service must remain logically isolated according to the organization boundary established by ADR-0002.

The logical service and tenant boundaries must remain valid regardless of the physical persistence strategy used to store the data.

Service Data Ownership

Each business service owns the operational data required to implement its business capability.

Examples include:

Customer Service
    -> Customer Operational Data

Inventory Service
    -> Inventory Operational Data

Warehouse Service
    -> Warehouse Operational Data

Purchasing Service
    -> Purchasing Operational Data

Order Service
    -> Order Operational Data

Fulfillment Service
    -> Fulfillment Operational Data

Shipping Service
    -> Shipping Operational Data

The owning service is responsible for:

  • Defining its data model
  • Maintaining business invariants
  • Validating organization ownership
  • Authorizing access to organization-owned resources
  • Persisting and retrieving its operational data
  • Managing changes to its persistence model
  • Managing data migrations within its ownership boundary
  • Publishing business events representing relevant state changes
  • Exposing required data through explicit service contracts
  • Preserving tenant isolation

The owning service is the authoritative source for its operational data unless another architectural decision explicitly establishes a derived or replicated representation.

No Cross-Service Database Access

A service must not directly read from or write to another service's operational data store.

For example:

Order Service
     |
     X----> Inventory Database

is not an allowed integration pattern.

Instead:

Order Service
     |
     +----> Inventory Service API

or

Order Service
     |
     +----> Business Event
              |
              v
        Inventory Service

Services obtain information owned by another service through explicit contracts such as:

  • Service APIs
  • Business events
  • Approved derived data
  • Explicit integration mechanisms defined by later architectural decisions

This preserves service autonomy and prevents database schemas from becoming implicit cross-service APIs.

Service Ownership and Organization Ownership Are Independent Dimensions

Service ownership and organization ownership represent different responsibilities.

For example:

Inventory Service
        |
        | authoritative for inventory data
        v
Inventory Operational Data
        |
        +---- Inventory Record A ---> Organization A
        |
        +---- Inventory Record B ---> Organization B

The Inventory Service owns the inventory data model and business rules.

Organization A owns its inventory resources from the tenant and business perspective.

Organization B owns its inventory resources.

Organization A must not gain access to Organization B's inventory simply because both organizations are served by the same Inventory Service or persistence infrastructure.

The service boundary determines who is authoritative for the data.

The organization boundary determines whose data an operation is authorized to access.

Organization Ownership Must Be Explicit

Organization-owned resources must have an explicit and enforceable association with their owning organization.

The exact technical representation of that association is not defined by this ADR.

It may eventually be represented through identifiers, partitioning metadata, schemas, databases, infrastructure boundaries, or other persistence mechanisms.

Regardless of implementation, the system must be able to determine which organization owns an organization-scoped resource and enforce that ownership during access.

Possession or discovery of a resource identifier does not grant access to the resource.

Tenant Isolation Is a Data Access Invariant

Tenant isolation is a required invariant of organization-owned data access.

Conceptually:

Organization Context
        |
        v
Service Authorization
        |
        v
Resource Ownership Validation
        |
        v
Tenant-Scoped Data Access

An operation executing for Organization A must not read, modify, delete, restore, migrate, or otherwise operate on Organization B's data unless an explicitly designed and authorized cross-organization capability permits it.

Cross-tenant access must be denied by default.

Tenant isolation must apply consistently to:

  • Reads
  • Creates
  • Updates
  • Deletes
  • Queries
  • Searches
  • Caches
  • Background processing
  • Scheduled jobs
  • Event-driven processing
  • Data exports
  • Imports
  • Analytics
  • Audit records
  • Backup and restoration
  • Data migrations
  • Administrative tooling

Missing, invalid, or unverified organization context must not broaden data access.

Services Enforce Their Own Data Boundary

Business services must enforce organization ownership and tenant isolation within their own service boundary.

Tenant isolation must not depend solely on:

  • Client behavior
  • User interface restrictions
  • API Gateway filtering
  • Authentication
  • Caller-supplied organization identifiers
  • Database query conventions
  • Upstream services
  • Developer discipline

Upstream controls may contribute to defense in depth, but the service responsible for an organization-owned resource remains responsible for enforcing access to that resource.

Tenant-Scoped Queries Must Fail Closed

Data access must be constrained to the validated organization context before organization-owned data is returned or modified.

Conceptually:

Validated Organization Context
              |
              v
      Tenant-Scoped Query
              |
              v
      Organization-Owned Data

A missing or invalid organization scope must not result in an unrestricted query.

For example, an implementation must not interpret the absence of organization context as:

SELECT all organizations

for an organization-scoped operation.

Platform-level operations requiring broader access must use separately authorized capabilities and must not be created by omitting tenant constraints.

Shared Infrastructure Does Not Imply Shared Access

Zelvoryqa may use shared infrastructure to serve multiple organizations.

Shared infrastructure may include:

  • Service instances
  • Compute resources
  • Databases
  • Caches
  • Messaging infrastructure
  • Search infrastructure
  • Analytical infrastructure
  • Object storage
  • Observability infrastructure

Sharing infrastructure does not weaken the logical tenant boundary.

For example:

             Inventory Service
                    |
          +---------+---------+
          |                   |
 Organization A          Organization B
 Inventory Data          Inventory Data

The organizations may share service and persistence infrastructure while remaining logically isolated.

Logical Isolation Is Required Regardless of Physical Storage Topology

This ADR requires logical tenant isolation but does not require a single physical storage topology for every organization or service.

Possible persistence models include:

Shared Database
     |
     +---- Organization A
     +---- Organization B
     +---- Organization C

or:

Shared Service
     |
     +---- Shared Persistence
     |
     +---- Dedicated Persistence for Selected Organizations

or other hybrid models.

Zelvoryqa may later use stronger infrastructure isolation for organizations with requirements involving:

  • Security
  • Regulatory compliance
  • Data residency
  • Enterprise isolation
  • Workload characteristics
  • Performance
  • Risk
  • Operational requirements

Business logic should not depend unnecessarily on whether organization data resides in shared or dedicated persistence infrastructure.

The initial physical tenant data strategy will be selected separately from this logical ownership model.

Derived and Replicated Data

A service may consume information originating from another service when that information is required to perform its own business capability.

Consuming or replicating another service's information does not transfer authority for the source data. The service that owns the originating business capability remains authoritative for that operational data.

For example:

Order Service
     |
     | OrderCreated
     v
Event Bus
     |
     +----> Inventory Service
     |
     +----> Fulfillment Service
     |
     +----> Operations Intelligence

The Inventory Service may consume order information required to reserve inventory.

The Fulfillment Service may consume order information required to coordinate fulfillment.

Operations Intelligence may consume the same event to maintain analytical projections, calculate operational metrics, identify trends, or support forecasting and optimization.

A consuming service may maintain a local representation of information originating from another service when required for its responsibilities. Such representations may include:

  • Event-derived state
  • Read models
  • Materialized views owned by the consuming service
  • Analytical projections
  • Search indexes
  • Cached representations

For example:

Order Service
     |
     | OrderCreated
     | OrderUpdated
     | OrderCancelled
     v
Event Bus
     |
     v
Fulfillment Service
     |
     v
Local Order Fulfillment View

The Fulfillment Service owns its local representation because that representation exists to support the fulfillment capability. However, the Order Service remains authoritative for the operational order state.

A consuming service must not treat replicated or derived data as authoritative for business state owned by another service.

When authoritative current state is required, the consuming service must use an appropriate contract with the owning service or another explicitly defined consistency mechanism.

Operations Intelligence is expected to consume information across many business capabilities because cross-domain analysis is part of its responsibility. This broader consumption model does not grant Operations Intelligence authority over the underlying operational data.

For example:

Order Service
     |
     | OrderCreated
     v
Event Bus
     |
     v
Operations Intelligence
     |
     v
Order Analytical Projection

The Order Service remains authoritative for the operational order state.

Operations Intelligence owns its analytical representation of that information, but not the underlying order.

Derived or replicated organization-owned data must preserve the organization boundary of its source data.

A local representation must not become a mechanism for bypassing the owning service's business authority or Zelvoryqa tenant-isolation requirements.

Caches Must Preserve Tenant Isolation

Caching must not weaken organization ownership or tenant isolation.

Organization-owned cached data must be scoped so that data belonging to one organization cannot be returned while processing another organization's operation.

Cache keys, namespaces, partitions, or equivalent mechanisms must preserve sufficient tenant scope.

The specific caching technology and cache-key strategy will be defined separately.

Search and Analytical Representations Must Preserve Tenant Isolation

Search indexes, analytical projections, reporting stores, and other derived representations of organization-owned data must preserve organization ownership.

A derived data store must not become a mechanism for bypassing tenant isolation enforced by the source service.

Organization-scoped queries against these representations must remain organization-scoped.

Cross-organization analytics require an explicitly authorized architectural capability rather than unrestricted access to tenant data.

Background and Asynchronous Processing Must Preserve Data Scope

Background jobs, event consumers, scheduled processing, retries, and recovery workflows operating on organization-owned data must preserve sufficient organization context to enforce the correct data boundary.

For example:

Organization A Event
        |
        v
Event Consumer
        |
        v
Organization A Context
        |
        v
Organization A Data

An asynchronous workload must not infer unrestricted access merely because no interactive user is present.

Service and workload identities remain subject to tenant isolation requirements.

Data Lifecycle Operations Must Preserve Tenant Boundaries

Tenant isolation applies throughout the data lifecycle.

Operations such as:

  • Backup
  • Restore
  • Migration
  • Archival
  • Retention
  • Export
  • Import
  • Replication
  • Reprocessing
  • Disaster recovery
  • Organization deletion

must preserve organization ownership.

Restoring or migrating Organization A's data must not overwrite, expose, merge with, or otherwise compromise Organization B's data.

Organization lifecycle changes must not cause organization-owned data to lose its ownership boundary or implicitly become platform-level data.

Rationale

Clear Sources of Truth

Service data ownership establishes an authoritative service for each operational data domain.

This prevents multiple services from independently modifying the same authoritative operational data.

Independent Service Evolution

Preventing direct cross-service database access allows services to evolve their internal schemas and persistence technologies without requiring unrelated services to understand those implementation details.

Stronger Microservice Boundaries

A database schema must not become an undocumented integration contract between services.

Explicit APIs and events create visible, testable, and versionable boundaries.

Tenant Isolation Becomes an Architectural Invariant

Tenant isolation is more reliable when it is treated as a fundamental data-access requirement rather than a convention applied by individual queries or user interfaces.

Shared Infrastructure Remains Possible

Logical isolation allows Zelvoryqa to operate efficiently as a SaaS platform without requiring dedicated infrastructure for every organization.

This supports cost efficiency while preserving the ability to introduce stronger isolation later where justified.

Physical Isolation Can Evolve

Separating the logical tenant model from the physical persistence topology allows Zelvoryqa to begin with an appropriate shared architecture and later introduce dedicated resources for selected organizations without redefining the business service model.

Derived Data Can Support Distributed Workflows

Allowing services to own derived representations enables asynchronous workflows, search, analytics, and Operations Intelligence without violating the authority of the originating service.

Alternatives Considered

Alternative 1: Shared Database Owned by Multiple Services

Multiple services directly access common operational tables.

Advantages

  • Simple initial implementation
  • Easy cross-domain queries
  • Fewer persistence components

Disadvantages

  • Strong coupling between services
  • Shared schemas become implicit APIs
  • Difficult independent schema evolution
  • Difficult independent deployment
  • Unclear data ownership
  • Increased risk of bypassing business rules
  • Increased tenant-isolation risk

Reason Not Selected

This conflicts with the service autonomy established by ADR-0001.

Alternative 2: Service-Owned Data Without Explicit Tenant Rules

Each service owns its data, but individual implementations determine how organization isolation is handled.

Advantages

  • Flexible implementation
  • Minimal architectural constraints

Disadvantages

  • Inconsistent isolation
  • Greater cross-tenant exposure risk
  • Tenant filtering may depend on developer discipline
  • Difficult security validation
  • Difficult organization-level recovery and migration

Reason Not Selected

Tenant isolation is a foundational property of Zelvoryqa and cannot be left to service-specific convention.

Alternative 3: Dedicated Persistence for Every Organization

Each organization receives dedicated persistence infrastructure.

Advantages

  • Strong infrastructure isolation
  • Clear tenant boundaries
  • Potentially simpler organization-level backup and restoration
  • Reduced risk of some cross-tenant query failures

Disadvantages

  • Higher infrastructure cost
  • Greater operational complexity
  • More difficult provisioning and lifecycle management
  • Larger number of databases and infrastructure resources
  • May be unnecessary for many organizations

Reason Not Selected

Dedicated infrastructure for every organization is not required to satisfy the logical tenant-isolation model and would impose unnecessary operational cost and complexity as the default architecture.

Alternative 4: Service-Owned Data with Logical Tenant Isolation and Evolvable Physical Isolation

Each service owns its operational data and enforces logical tenant isolation, while the physical persistence topology may evolve based on organizational requirements.

Advantages

  • Clear service ownership
  • Strong logical tenant boundaries
  • Supports shared SaaS infrastructure
  • Enables independent service evolution
  • Allows stronger isolation later
  • Supports hybrid persistence strategies
  • Aligns with ADR-0001 and ADR-0002

Disadvantages

  • Requires disciplined tenant-aware data access
  • Requires isolation testing
  • Shared persistence requires careful implementation
  • Organization migration between storage boundaries may require tooling

Reason Selected

This model provides the best balance between service autonomy, SaaS efficiency, tenant security, operational flexibility, and future evolution.

Consequences

Positive Consequences

  • Every operational data domain has an authoritative service.
  • Cross-service database coupling is prohibited.
  • Tenant isolation becomes a system invariant.
  • Organization ownership is explicit.
  • Shared infrastructure remains possible.
  • Physical isolation can evolve independently from business logic.
  • Services can change internal persistence models more independently.
  • Derived data models can support analytics and asynchronous workflows.
  • Cross-tenant access patterns become easier to identify and test.

Negative Consequences

  • Cross-domain queries cannot rely on direct database joins.
  • Services may need APIs, events, or derived read models for cross-domain information.
  • Some data may be duplicated in derived representations.
  • Tenant-aware data access increases implementation complexity.
  • Backup, restoration, and migration procedures must understand organization ownership.
  • Shared persistence requires strong isolation controls and testing.

Risks

  • Missing tenant scope could expose data across organizations.
  • Incorrect resource ownership validation could allow ID-based cross-tenant access.
  • Cache keys could omit tenant scope.
  • Derived stores could lose organization ownership metadata.
  • Background jobs could execute without sufficient organization context.
  • Administrative tooling could accidentally bypass tenant restrictions.
  • Data migrations could weaken tenant isolation.
  • Backup or restoration procedures could mix organization data.
  • Shared infrastructure could create noisy-neighbor or capacity issues.
  • Future physical isolation changes could become difficult if business logic depends on storage topology.

Implementation Considerations

Future implementation must define:

  • Organization ownership representation
  • Tenant-scoped persistence patterns
  • Resource ownership validation
  • Query-scoping conventions
  • Repository or data-access abstractions
  • Persistence technology
  • Shared versus dedicated persistence strategy
  • Database migration patterns
  • Cache isolation
  • Search isolation
  • Analytical data isolation
  • Backup and restoration boundaries
  • Organization migration mechanisms
  • Data retention and deletion
  • Administrative access patterns
  • Cross-tenant isolation testing

Implementation should make unsafe unscoped organization-data access difficult to perform accidentally.

The exact mechanisms are intentionally not defined by this ADR.

Operational Considerations

Operational tooling must preserve service ownership and organization boundaries.

Database administration, debugging, support tooling, migration utilities, and incident-response procedures must not create implicit tenant bypasses.

Privileged access to organization-owned data must be explicitly authorized and auditable.

Backup, restoration, migration, archival, and disaster-recovery processes must preserve organization ownership and tenant isolation.

Operational procedures should support organization-specific recovery where practical without compromising other organizations.

Shared persistence infrastructure requires monitoring for:

  • Capacity
  • Resource contention
  • Noisy-neighbor behavior
  • Storage growth
  • Query performance
  • Tenant fairness
  • Isolation failures

Organizations requiring stronger infrastructure isolation may eventually be moved to dedicated persistence or other isolated infrastructure without changing the fundamental service ownership model.

Validation

This decision will be considered successfully implemented when Zelvoryqa can demonstrate that:

  • Each operational data domain has a clearly identified authoritative service.
  • Services do not directly access another service's operational data store.
  • Organization-owned resources have an enforceable organization association.
  • Organization-scoped operations require valid organization context.
  • Organization A cannot read Organization B's data.
  • Organization A cannot modify or delete Organization B's data.
  • Possession of Organization B's resource identifier does not grant Organization A access.
  • Missing organization context does not result in unrestricted data access.
  • Invalid or manipulated organization context is rejected.
  • Shared service instances can safely process data for multiple organizations.
  • Shared persistence can maintain logical tenant isolation when used.
  • Caches preserve tenant boundaries.
  • Derived data preserves organization ownership.
  • Search and analytical representations preserve tenant boundaries.
  • Event-driven and background processing preserve organization scope.
  • Service and workload identities do not implicitly bypass tenant isolation.
  • Backup and restoration preserve organization ownership.
  • Organization-specific restoration does not expose or overwrite another organization's data.
  • Data migrations preserve tenant boundaries.
  • Administrative and support tooling does not create implicit tenant bypasses.
  • Isolation behavior is covered by automated tests.

Follow-Up

The following architectural decisions build on this ADR:

  • ADR-0004: Adopt Event-Driven Integration
  • ADR-0005: Define Synchronous Service Communication
  • ADR-0006: Define Authentication, Organization Membership, and Authorization
  • ADR-0007: Define API Gateway and External API Architecture

Additional later decisions will define:

  • Persistence technology and implementation patterns
  • Database migration strategy
  • Caching strategy
  • Search architecture
  • Operations Intelligence data architecture
  • Backup, restore, and disaster recovery
  • Audit logging
  • Analytics and AI isolation requirements

References

  • ADR-0001: Adopt Microservices Based on Business Capabilities
  • ADR-0002: Adopt Multi-Tenant SaaS Architecture
  • Zelvoryqa Architecture Overview
  • Zelvoryqa Product Vision
  • Zelvoryqa Goals

Status Definitions

  • Proposed — The decision is under review.
  • Accepted — The decision has been approved and should guide implementation.
  • Deprecated — The decision is no longer recommended but remains for historical context.
  • Superseded — The decision has been replaced by a newer ADR.

ADR Guidelines

This ADR records one significant architectural decision.

The ADR should:

  • Explain the context that required the decision.
  • State the decision clearly.
  • Document the reasoning behind the decision.
  • Record meaningful alternatives and tradeoffs.
  • Separate durable architectural requirements from implementation details.
  • Avoid selecting technologies that belong in later decisions.
  • Be superseded rather than rewritten when the architectural decision fundamentally changes.