Global Replication, Multi-Region Writes, Conflict Semantics, and Regulatory Data Residency

1. “Global” names a placement feature; it does not tell you what happened to a write

AtlasMart wants customers in Europe, North America and Asia to use nearby application endpoints. There are at least three distinct designs. A single-writer global design sends authoritative writes to one region and asynchronously or synchronously replicates elsewhere. A multi-writer/active-active design accepts writes in several regions and therefore needs explicit concurrent-write semantics. A strong multi-region design coordinates across regions before acknowledging relevant writes/reads. These choices alter latency, RPO, availability during partitions and conflict handling.

Do not infer semantics from the phrase “global database.” As of August 2026, DynamoDB global tables distinguish multi-Region eventual consistency (MREC) from multi-Region strong consistency (MRSC); MREC uses asynchronous replication and last-writer-wins conflict resolution, while MRSC has different topology and latency requirements. Azure Cosmos DB exposes its own consistency spectrum. Firestore chooses a fixed regional or multi-region location and documents strong consistency with its own replication architecture. These are examples of why the product contract must be read, not normalized into one slogan.

2. Trace the write path, conflict rule, and failover path separately

For every design, AtlasMart records where the client writes, which replicas must acknowledge before success, what a remote read may observe, how concurrent writes are detected/resolved, and what happens when one region is isolated. A multi-writer eventual design can keep local write latency low but may expose stale remote reads and conflict resolution. A synchronous design can reduce or eliminate replication RPO for supported operations but adds cross-region coordination to the critical path.

3. Deliberately wrong approach: multi-region LWW as a universal merge strategy

Two regions edit different fields of the same logical object while disconnected. Whole-item LWW converges to one object, but convergence can discard meaningful intent. The lab shows an email change and a loyalty-tier change collapsing to the timestamp winner. A domain merge can preserve independent fields, but that is application logic with its own audit and conflict requirements. For invariants such as payment capture or inventory allocation, stronger coordination or redesigned ownership may be required rather than clever merging.

4. AtlasMart lab: conflict convergence plus a residency-constrained failover

from dataclasses import dataclass

@dataclass
class Version:
    region: str
    ts: int
    value: dict

# Same AtlasMart customer profile is edited independently during a partition.
base = {"email": "a@example.test", "loyalty": "silver"}
us = Version("us", 101, {"email": "new@example.test", "loyalty": "silver"})
eu = Version("eu", 104, {"email": "a@example.test", "loyalty": "gold"})

# Whole-item last-write-wins converges, but discards one independent business change.
lww = max([us, eu], key=lambda v: (v.ts, v.region))
print("MREC-LIKE WHOLE-ITEM LWW")
print("US version:", us)
print("EU version:", eu)
print("winner:", lww)
print("lost email change?", lww.value["email"] != us.value["email"])

# A domain-aware merge keeps the independent fields. This is application semantics, not LWW.
merged = dict(base)
merged["email"] = us.value["email"]
merged["loyalty"] = eu.value["loyalty"]
print("domain-aware merged state:", merged)

# Residency policy is independent of replication availability.
tenant_policy = {
    "tenant-eu-regulated": {"allowed_regions": {"eu-west", "eu-north"}},
    "tenant-global": {"allowed_regions": {"eu-west", "us-east", "ap-south"}},
}

def can_route(tenant, region):
    return region in tenant_policy[tenant]["allowed_regions"]

print("\nREGIONAL FAILOVER POLICY")
for tenant in tenant_policy:
    for target in ["eu-west", "us-east"]:
        print(tenant, "->", target, "allowed=", can_route(tenant, target))

print("wrong failover: route every tenant to us-east when EU is impaired")
print("regulated tenant violation=", not can_route("tenant-eu-regulated", "us-east"))
print("safer behavior: fail closed/degraded for that tenant unless an approved in-policy region is available")

5. Production judgment: pin exact service, mode, regions, and legal boundary

Before production, create a region matrix with exact service edition/API, consistency mode, permitted writer regions, replication behavior, supported strong-read operations, conflict handling, RPO/RTO, quotas, key-management support, private connectivity, backup geography, and data-residency approval. Re-run this verification during migration because global features evolve; DynamoDB’s MRSC mode is a concrete example of a capability that changed the service’s option set over time.

Test real partition and failover histories in a staging account where feasible, but do not make a paid cloud topology mandatory for learning. Validate that a failover controller respects tenant policy, not only health checks. The next lesson examines the broader managed operating surface—backups, upgrades, observability, private networking and service-specific dependencies—that can fail even when replication itself is working.

References

Provider-specific claims below are current implementation anchors reviewed in August 2026. They are not universal NoSQL definitions, and mandatory labs do not require the services.

• Amazon DynamoDB — Global tables — Current official MREC/MRSC consistency-mode overview.
• DynamoDB — How global tables work — Current official details for asynchronous MREC/LWW and MRSC tradeoffs.
• Azure Cosmos DB — Consistency levels — Official consistency/throughput/global-write semantics and distance caveats.
• Google Cloud Firestore — Locations — Official regional and multi-region replica placement and location immutability.
• Cloud Firestore — Real-time queries at scale — Official explanation of multi-region tradeoffs, strong consistency and hotspot considerations.