Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket is explicitly multi-datacenter and supports site-aware placement and failover.
That creates a new requirement: some tenants, products, or datasets may need placement restrictions. Without an explicit policy model, the platform risks making placement promises it cannot enforce or silently moving data in ways that violate operator or tenant expectations.
Decision
Dataverket treats data residency and placement policy as a first-class scheduling and control-plane concern.
The platform must be able to express and enforce:
- preferred datacenter placement
- restricted datacenter placement
- product-specific placement limitations
- failover rules that respect placement constraints
Scope
Placement and residency policy may apply to:
- VMs
- Kubernetes clusters
- databases
- buckets and object placement policy where supported
- tenant applications and their backing services
Not every product needs the same policy depth, but the platform must support the concept consistently.
Policy classes
The platform should support at least:
Preferred placement A workload should run in a preferred site when possible.
Restricted placement A workload or data set may only exist in approved sites.
Failover-constrained placement Failover is allowed only to a specific subset of sites.
Relationship to failover
Failover policy must not override residency policy silently.
If a workload is restricted to one site or a specific set of sites, failover logic must respect that constraint even when broader platform failover would otherwise be possible.
Control-plane implications
The platform must carry placement and residency context through:
- API resources
- task creation
- scheduling and allocation logic
- operator visibility
Placement policy that exists only in external documentation is not sufficient.
At the public API level, relevant resources and tasks should be able to express at least:
- requested or desired placement policy
- current site or placement outcome where applicable
- allowed failover targets where the product supports failover
- policy validation failures when a request conflicts with placement rules
Operator and tenant visibility
Operators and, where appropriate, tenants should be able to see:
- current placement
- allowed sites
- whether a requested failover target is policy-compliant
- which resource classes have explicit residency restrictions
Explicit non-decisions for now
This ADR intentionally does not yet choose:
- exact policy syntax
- exact default rules by product
- exact enforcement location between API, scheduler, and domain services
Those require later implementation decisions.
Consequences
- multi-datacenter placement becomes policy-driven rather than purely opportunistic
- failover claims become more honest because they must account for residency constraints
- later scheduling and quota work must integrate with policy rather than bypass it
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- Tenant scoping must align with 009-resource-inventory-and-tenancy-model.md.
- Failover behavior must align with 012-inter-datacenter-topology-and-failover.md.
- Storage-backed data placement must align with 015-storage-platform-and-persistence-strategy.md.
- Operator visibility must align with 022-operator-visibility-and-control-surface.md.
More Information
- placement policy schema
- enforcement model for schedulers and domain services
- product-specific residency defaults
Audit
- 2026-03-14: ADR proposed.