Replication is set up by a storage team solving a durability problem. A second copy is placed far enough away that a single event cannot take both, the configuration is tested, and the matter is closed. That same configuration determines which jurisdictions hold the data, and the consequence is rarely written anywhere a compliance reviewer would find it. The distance that makes a copy safe is frequently the distance that moves it across a border.
The mismatch is structural. Durability is expressed in failure domains, drawn to be independent, which usually means far apart and often differently governed. Residency is expressed in jurisdictions. Nothing in a replication configuration screen asks which of the two is being decided, and the default answer is durability, since that is the problem the operator came to solve.
The reviewable form of a boundary is not a policy document stating that data remains in a territory. It is a configuration that cannot place data outside that territory, together with a way to demonstrate that no exception exists. Those are different artifacts, and most organizations have the first.
Where the placement decision is actually made
Placement is set in more than one layer, and layers can disagree. A system-level placement policy determines the default spread of data across nodes, racks and sites for everything the namespace holds. A bucket-level or container-level replication rule then adds destinations for a subset of objects, usually selected by prefix or tag. A third layer, tiering or lifecycle transition, can move objects to an entirely different class or provider later in their life.
The scope difference matters most when a new bucket appears. If replication is defined per bucket, a bucket created next quarter by a team that did not read the standard has no rule and no boundary statement attached. If placement is defined at system level, the boundary holds by default and exceptions require deliberate action. Default-safe and default-silent are the two postures, chosen by where the rule is written rather than how strictly it is worded.
Metadata follows its own path. Object names, sizes, timestamps, tags and index structures are often replicated on a different schedule or to a different place from payload, and an index service may be centralized even when data is not. Where object details are stored is a separate question from where objects are stored, and it should be answered separately.
What synchronous and asynchronous choices imply
Synchronous replication commits a write at every participating site before acknowledging it. Its sovereignty property is exactness: at acknowledgment the set of locations holding the data is known and complete, with no window in which the copy set is ambiguous. Its cost is that every site is on the write path, so latency and availability are bound to the slowest and least reliable member.
Asynchronous replication acknowledges locally and propagates afterward. The copy set at any instant is the local site plus whatever the queue has delivered, which makes the boundary a statement about eventual rather than current state. That is usually acceptable, but it introduces two questions worth answering explicitly: how large the replication backlog can grow, and where the queued data physically sits while it waits.
A queue draining to a remote site holds data in transit, and a stalled queue can hold it for a long time. If that queue is buffered on intermediate infrastructure, the infrastructure is part of the boundary whether or not it appears on the architecture diagram.
| Configuration | What it does to placement | What to verify |
|---|---|---|
| System-level placement policy | Sets the default spread for all data in the namespace | The site list and whether any per-bucket setting can override it |
| Bucket-level replication rule | Adds destinations for a filtered subset of objects | Whether newly created buckets inherit a rule or start with none |
| Synchronous multi-site write | Fixes the copy set at acknowledgment | Behavior when one site is unreachable, and whether writes continue |
| Asynchronous replication | Copies land after acknowledgment, on a variable delay | Maximum backlog, and where queued data is buffered while pending |
| Erasure coding across sites | Places fragments, not whole copies, at each location | Fragments per site and how many sites can reconstruct without the others |
| Failover or site promotion | Changes which location serves and accepts writes | Whether the promoted site was inside the stated boundary |
Why erasure coding across sites behaves differently
Replication places whole, independently readable copies. Erasure coding places fragments, and a fragment is not readable on its own. Spreading fragments across sites therefore produces a different sovereignty statement: no single site holds the data, but some combination does, and the size of that combination is set by the coding scheme.
The practical question is how many sites are required to reconstruct. A scheme in which any single site holds enough fragments to rebuild an object independently is, for residency purposes, closer to replication. A scheme requiring fragments from several sites means that a legal order served on one location yields material that cannot be reassembled there. That distinction is weaker than it sounds if the same operator controls every site, since the operator can combine the fragments.
The durability and capacity tradeoffs are covered by the usual comparison of erasure coding and replication. Less often noted is that the choice sets the granularity at which a boundary can be described, in fragments and reconstruction thresholds rather than in copies.
What failover does to the boundary
A boundary defined on the steady state says nothing about the failed state. Failover promotes a standby site to serve reads and accept writes, and that site may have been included as a durability member without anyone asking whether it was inside the residency statement. Data that was only ever a fragment or a passive copy at that location becomes actively served from it.
Two behaviors deserve testing. Whether failover is automatic, since an automatic promotion crossing a border happens without an approval step or a notification. And what the system does during failback, since resynchronization moves data the other way and can leave residue at the promoted site.
These questions belong in the same exercise as the recovery test itself. A disaster recovery design that avoids shared failure should also state, for each failure scenario, which jurisdictions serve the workload while the scenario is active.
Where Scality RING fits
RING is software-defined object and file storage running on standard servers in facilities the customer operates, presenting a single namespace across nodes and sites. Because the operator selects the sites and configures how data is spread among them, geographic placement is explicit configuration rather than a region label assigned by a provider. The same mechanism that allows a whole site to be lost without data loss is the one that decides where data resides, which makes durability and residency a single, inspectable setting rather than two disconnected claims.
RING supports both erasure coding and replication, selectable per policy, so a data set can be protected by whole copies at named sites or by fragments spread across them, with the residency consequence recorded either way. Since the deployment sits on customer-controlled infrastructure, the controlling entity for every site is the customer rather than an operator whose corporate structure must be traced.
Expressing the boundary as configuration and checking it
Write the boundary as a list of permitted sites or regions, then locate every setting that could place data outside that list: system placement policy, per-bucket replication rules, lifecycle and tiering transitions, DR relationships, and any default applied to newly created buckets. Record for each the current value and the mechanism that would prevent a change, since a value without a guard is a preference rather than a control.
Export those settings on a schedule and compare them to the previous export, treating any difference as a change requiring an owner and a reason. Machine-readable exports matter because the number of settings is larger than a person will check by hand. Include the export in the evidence set for any sovereignty audit, and add a failover test to the same cycle, so the boundary is demonstrated in the failed state as well.