Write-Anywhere Availability and Conflict Resolution

Traditional database architectures have historically relied on a single-writer or single-leader model for handling write requests. In the single-writer approach, one primary site is responsible for processing all write operations, often supported by a hot standby replica that can take over during failures. Read scalability is then typically achieved by deploying read-only replicas or caches that serve queries without modifying data. It should be noted that such a system is already subjected to eventual consistency, as data caches cannot guarantee to have the latest data state at all times.

This has a fundamental limitation: write throughput is constrained by the capacity of a single node or location. As workloads that necessitate high write throughputs grow in demand (especially applicable to the needs of the 5G SA), scaling becomes increasingly difficult or impossible. In addition, write traffic is limited to the location of the writable instance, making it impossible to fully utilize distributed infrastructure or maintain low-latency writes across geographical regions.

Figure 3: Visualization of a single-write architecture.

A variation of this traditional design is the so-called single-leader approach, in which multiple sites may accept write requests, but each database record is assigned to a single specific leader site. If a client attempts to update a record on a site that does not hold the leadership for that record, the request is automatically (re)routed to the assigned leader.

Figure 4: Visualization of a write request re-route in a single-leader architecture.

This approach may appear attractive at first because it avoids concurrent write conflicts and prevents stale reads, but the inherent fragility and latency costs of traversing wide-area networks remain unavoidable, leading to:

• High client response latencies: re-routed client requests incur wide-area network latency and variance.
• Network fragility becoming user-visible: packet loss and jitter translate into timeouts and retries.
• Complex failover decisions: leader election/ownership transfer must balance rapid recovery against split-brain risks (multiple replicas acting as leaders that serve the same data).
• Scalability ceilings: leaders become coordination chokepoints; re-routed traffic becomes a disproportionate contributor to tail latency.

The PACELC theorem predicts this systematically: maintaining strong consistency without partitions still necessitates latency costs due to coordination.

Enea’s Stratum design allows clients to perform writes on any site (“multi-writer”, “multi-active”); a deliberate first principle aimed at achieving high availability and low client response latency.

This is consistent with the design intent of so-called “optimistic” replication families: replicas remain available and responsive, and updates propagate and converge asynchronously as connectivity permits.

Figure 5: Visualization of a write to local site in a multi-writer architecture.

It is intuitively clear that if clients are allowed to write to any site at any time, concurrent updates to the same record across sites can lead to conflicts, especially in geographically distributed systems, where network delays or partitions are common. Naively allowing multiple clients to write simultaneously risks producing incorrect data states unless conflicts are carefully managed.

One fundamental approach to avoiding such conflicts is thoughtful data modeling: independent clients operate on separate, non-overlapping update domains, such as different records or distinct fields within a record. Another strategy is session affinity, where clients “stick” to a particular site for the duration of a request flow, ensuring that writes remain localized. Beyond these measures, deterministic merge semantics are applied by the database so that, when concurrent updates do occur, replicas reconcile them in a predictable and safe manner, guaranteeing that all sites converge to a consistent state without manual intervention.

Conflict-free Replicated Data Types (CRDTs) formalize this merge principle. CRDTs are data structures that allow replicas to accept updates independently while guaranteeing convergence of the data once all updates have been received. By design, they provably ensure that the data will converge safely and correctly, even in the presence of concurrent writes or prolonged network partitions. Many modern database have opted to implement some form of CRDTs to achieve strong eventual consistency without requiring centralized coordination across datacenters.

Stratum’s document storage engine implements CRDT-like deterministic merging, allowing local, low-latency writes on any site while guaranteeing that concurrent modifications converge safely and predictably. For example, if two clients update the same document concurrently on different datacenters, merge semantics ensure that both updates are preserved and automatically reconciled, resulting in a single, well-defined document state.

Figure 6: Merge of two concurrent Add operations for the same record on different datacenters.