Replicated Record Store¶

Replicated data store — instantiates Asynchronous Replica Convergence

Keeps the same records on multiple independently-writable replicas so every site stays available locally — the substrate the whole convergence process runs on.

Replicated Record Store is the substrate the rest of this archetype acts on: the same records held on several replicas, each able to accept reads and local writes without waiting for the others. Its one defining job is to make copies exist and stay locally available — to define which replicas hold which data and how records are spread across them — so a site can keep working through a partition or an outage. It deliberately does the least about agreement: it is not the merge, the repair, or the causal bookkeeping, but the place those mechanisms run. Everything else here — reconciliation, read-repair, tombstones, version vectors — presupposes a store that already lets divergence happen. This is that store.

Example¶

A utility's field-service app runs on tablets carried by 300 technicians. Each tablet holds a replica of the work-order database for its region, and — this is the point — each can write: a technician in a basement with no signal marks a job complete, adds meter readings, and reorders their queue, all against the local copy. The store's setup is two decisions. Membership and scope: the replica set is the 300 tablets plus a central cluster, and each tablet carries only its region's open work orders, not the whole company's. Replication rule: every work order is owned by its region and copied to that region's tablets and the center, so a lost tablet loses nothing.

Through a four-hour dead zone the technician keeps working at full speed. When the tablet reconnects, its local edits and the center's are still divergent — and the store hands that divergence to the convergence machinery to reconcile. What the store guarantees on its own is only this: the copies exist, and every one of them stayed writable.

How it works¶

What distinguishes the store from its siblings is that it is plumbing, not policy. It answers two questions and no others: who holds a copy — the replica set and each replica's scope, full or partial — and how records map onto those replicas — replication factor, ownership, sharding. It accepts local writes without coordination and exposes the resulting replicas for other mechanisms to converge. It makes no promise about which value is correct when copies disagree; that is handed off. A store that also merged, ordered, and repaired would be the whole archetype, not one mechanism in it.

Tuning parameters¶

Replication factor — how many replicas hold each record. More copies survive more simultaneous failures and sit nearer to readers, but multiply the writes that must later converge and the storage they cost.
Partitioning / ownership scheme — how records are sharded and which replica "owns" each. Aligning partitions to access locality keeps most work local; a poor scheme scatters related records and forces cross-replica traffic.
Write locality — whether every replica accepts writes (multi-master) or each key has a single writer. Multi-master maximizes local availability but creates the concurrent-update problem the rest of the archetype exists to solve.
Replica scope — full replicas (every record everywhere) versus partial replicas (each site holds only what it needs). Partial replicas cut storage and sync load but complicate membership and routing.

When it helps, and when it misleads¶

Its strength is availability under partition: because every replica is independently writable, no site's work stops when the network does — exactly the trade a distributed store is usually there to make.^[1] Its honest limit is that availability is all it gives you. A replicated store, by itself, has no convergence guarantee; drop the reconciliation, merge, and causal-tracking mechanisms and you get copies that cheerfully accept conflicting writes and never agree again. The classic misuse is exactly that complacency — "we replicate, therefore we're consistent" — treating the existence of copies as if it implied they hold the same thing. The discipline is to remember the store is deliberately half a solution: pair it with an explicit convergence contract, a merge rule, and a repair path, and never let "replicated" be mistaken for "converged."

How it implements the components¶

Replicated Record Store fills only the substrate components — the ones a place data lives can fill:

replica_membership_and_scope — it defines the replica set and each replica's scope: which sites hold a copy, and whether that copy is full or partial.
replication_or_partitioning_rule — it sets how records are copied and sharded across replicas: replication factor, ownership, and partition boundaries.

It does not enforce that the replicas ever agree — that convergence guarantee is Anti-Entropy Reconciliation Exchange's — nor decide how two concurrent values combine (CRDT-Like State Merge) or carry the causal metadata that tells newer from concurrent (Version-Vector or Dotted-Context Exchange). The store is the surface they operate on.

Instantiates: Asynchronous Replica Convergence — it is the multi-writer substrate whose deliberate divergence the rest of the archetype converges.
Sibling mechanisms: Anti-Entropy Reconciliation Exchange · Version-Vector or Dotted-Context Exchange · Read Repair on Access · Merkle-Tree Divergence Scan · Hinted-Handoff Buffer · CRDT-Like State Merge · Replica Repair Job

Notes¶

A replicated store here is not a backup. Backup keeps an extra, passive copy so data survives loss; this store keeps active, writable copies so work survives disconnection — and that writability is precisely what creates divergence and makes the rest of the archetype necessary. Keeping the two ideas apart matters: a read-only standby needs none of the convergence machinery on this page.

References¶

[1] The CAP theorem — a replicated store facing a network partition can preserve availability or strong consistency, not both. This archetype takes the available branch on purpose: replicas keep serving and accept temporary divergence, then converge afterward, which is why the store supplies availability and defers the consistency work to its siblings. ↩