Primary-replica versus peer replication

01Where can a write be accepted?

Order records are copied onto several machines so one machine's failure need not remove the only copy. Decide which machine may accept a change and what happens if two places receive changes together.

• Primary-replica: one current primary orders writes for a defined set of records and sends changes to followers. Different data partitions can have different primaries; this does not imply one global writer for the entire database.
• Peer, multi-leader or leaderless approaches: more than one node may accept or coordinate requests for the relevant data. The exact protocol decides how replicas acknowledge and resolve them.

Multiple entry points can reduce geographic distance or preserve selected operations during failures. They do not automatically make conflicting stock or balance changes safe. Every design still needs a write-order or conflict rule, a definition of success and a recovery plan.

02Acknowledgment determines exposure to failure

Place order 42 on primary P with followers A and B. These machines hold one shard: a subset of records, such as orders for a range of customer IDs.

Trace replica progress

1. Receive: a follower gets update bytes over the network.
2. Persist: it saves them through the failures covered by its storage guarantee.
3. Apply: it changes the state queries can read.

A write response may wait for different steps. “Synchronous” alone does not prove every follower already answers current queries. Asynchronous success can precede followers receiving the new write.

Now explain blocking an old primary, called fencing

1. The coordination system grants P write permission number 12. Requests to the replicas or storage carrying P's writes include that number.
2. After the coordination system selects one replacement and recovers the committed orders, it grants that primary number 13. The replicas or storage that accept writes record 13 before the replacement starts changing records.
3. Every write-accepting participant checks the permission number together with accepting the change, as one indivisible operation. Once 13 is current, a request carrying 12 fails that check and cannot change the record. Checking 12 earlier and later performing an unchecked write would leave another race; changing a hostname cannot enforce this either.
4. For example, require two of the three replicas to save every accepted write and to adopt the replacement’s permission. After A and B adopt 13, isolated P with 12 cannot obtain the two acceptances needed to report success, even if it changes its own local bytes.

These checks enforce a winner; they do not choose one or determine which writes committed. The coordination system needs a proven election and commit protocol that selects one replacement containing the committed history, such as Raft. A timeout, a larger number or two arbitrary responses alone does not provide that protocol.

03Worked example: a three-replica register

First follow an asynchronously copied write

1. P saves order version 8 locally and tells the client it succeeded. A and B still hold 7.
2. P's only saved copy is permanently lost before replication.
3. Promoting A recovers only what survives on A; it cannot invent version 8's missing bytes.
4. For a one-machine-loss promise, a concrete protocol can wait until P and another machine A have durably stored the committed version 8 before replying. If P fails, A still has 8. A replacement cannot simply use B's old 7; recover the required committed state from a surviving copy under the chosen commit/promotion protocol.
5. Enforce the new writer permission before accepting conflicting old-primary writes.

Read after saving version 8

1. The caller carries the required version 8. A selected follower reports applied/query-visible version 7, so it cannot answer that request yet.
2. Wait for that follower to apply 8, route to the valid current primary, or fail under the stated policy.
3. This minimum-version check provides read-your-writes, not global linearizability alone. For example, a Raft-style primary first commits an entry for its leadership period. For a read, it obtains confirmation from a majority that it is still leader, then waits until its query state has applied through the committed position established for that read. Without those confirmations or applied progress it waits or fails; a stale health check is insufficient. This is a database protocol, not an extra client-side version comparison.

Now examine one value on a fixed replica set A, B and C without one fixed write-entry primary

• N=3 means three copies exist.
• W=2 means a successful write waits for two acknowledgments.
• R=2 means a read consults two replicas.

A write saved on A/B and a read consulting B/C overlap at B. Since R + W > N, any such completed participant sets intersect. With R=1, a read choosing only C can miss the write.

Intersection alone does not prove linearizability. The read must choose or reconcile versions correctly, and the protocol must handle concurrent writes, failed attempts, changed replica membership and repairs. Timestamp-based last-write-wins can converge while discarding a valid change. Also keep historical backups: live replication can copy an accidental deletion to every current replica.

04Pick authority before drawing copies

Choose the write behavior before drawing copies:

• One current primary per shard can simplify enforcing record rules in one ordered path.
• Peer write entry can fit operations that still make sense when accepted separately, such as different users adding distinct comments. Two disconnected nodes cannot independently promise the same last seat merely because they can later choose one record.
• Acknowledgment must name received, durable or applied progress, and independent copy placement.
• Failover must select sufficiently current state and block the former writer at the write-accepting participants.
• Reads must establish the freshness required by that operation. A live follower can still be too old.
• Unavailable participants require an explicit wait/reject or weaker-operation policy. Waiting for a remote durable copy can add delay or reduce availability during its outage.

Trace a process crash separately from a still-running but network-isolated primary. Those situations show why copying data, finding a responsive server and granting write permission are different responsibilities.