MechanismChapter II · Data · Building block 5 of 9

Replication

Replication keeps copies of data in multiple locations. There may be a measurable delay between writing and taking over by a copy.

  1. DelaysThe replica follows the original by distance.
  2. AgeingWho reads in the window, sees the old value.
  3. Price of reading on the originalCurrently reading loads the writing system.

Context

Why this is important

A copy of the reader relieves the burden on the writing system, but provides an older status. Synchronous replication waits for the copy and is slower; asynchronous is fast, allows for delay and can lose changes on failover. The business commitment deals with consistency models.

This building block explains data copies and replication delay. For the business visibility commitment, see Consistency Models.

At a glance · Leader with Replikas

The leader accepts all write accesses and copies them to the replicas; read by the replicas.
Shop example · Playing through stages

Replication delay and status of B-1042

Variant: The shop uses a reader copy of the order database for customer service queries in order to keep many queries away from the writing system.

This is how you read the picture

  1. Delays You stop the delay; the replica shows paid only afterwards.
  2. Ageing Absence 2 s delay shows the query about 12:00:01 “Payment open.”
  3. Price of reading on the original With counters, the customer service sees paid, the primary database carries more load.
  • Open paymentResponse to 12:00:01
  • 12:00:03Replica current off

Delay as in the example: First 12:00:03 shows the replica paid. Then ask the question. 12:00:01 See the old state.

Values illustrative

Customer service asks B-1042 Circum 12:00:01 The change is made to paid for 12:00:00. Change the delay and read off the result.

Benefits & limitations

Helps if:

  • Many readers benefit from copies that distribute read access to the same data.
  • Additional replicas provide accessible copies during outages or across geographical locations.
  • When the business accepts measurable read lag, asynchronous replication reduces the work required before acknowledging writes.

Boundaries

  • Asynchronous replication has a delay: Who reads in the window, sees an older state.
  • During the failover, changes may be missing that the replica had not yet adopted.
  • Replication also propagates accidental deletions and incorrect changes; independent backups are needed for recovery from these. Consistency Models defines the guarantees to readers.

In practice

  1. Choose synchronous or asynchronous acknowledgement according to the acceptable data-loss window and freshness requirements. Record when a change is considered durable from the caller's perspective.
  2. Route reads only to replicas with a suitable freshness guarantee. Measure replication lag and rehearse failover, including reconciliation of the returning node.
  3. Keep replication separate from independent backups. Consistency Models defines permitted read states; Quorum describes acknowledgement groups.
Read the detailed explanation

Replication maintains multiple copies of a dataset and transfers changes between them. Acknowledgement rules determine when a write is considered complete. Asynchronous replicas may lag; synchronous acknowledgement waits for additional participants and may increase latency.

Replicas support read scaling and failover but do not replace independent backups. Read paths must state their freshness guarantees. Leader changes, possible data loss and restart procedures need tested rules.

Consistency Models describes the view a reader receives; Quorum defines which replica responses suffice for an operation.

Leader/Follower is a common arrangement; a replica used for reads is also called a Read Replica.

The acceptable data-loss window during failover is expressed as the RPO (Recovery Point Objective): the maximum amount of recent changes that may be lost. Synchronous replication reduces this window at the cost of write latency.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    What does the query show about 12:00:01 at 3 s delay, and what changes the switch?

    View the solution with justification

    "Payment open" because the replica takes over only 12:00:03. With switch: paid, but more load on the primary database.

  2. ApplyingTransferred to a new situation

    Customer service asks about 12:00:02 ab. What to expect?

    View the solution with justification

    Payment still open, because replication has changed only to 12:00:03 taken over. A later query shows paid.

  3. EvaluateWeighing an alternative

    Should customer service instead read the primary database directly? How do you weigh up?

    View the solution with justification

    The status would be current, but the many queries burden the writing system again. The replica creates reading capacity against the price of a possible delay.

Explore further

These optional deepenings complement the learning goal of this page.

WAL and replicated log

A Write-Ahead Log records changes locally before database pages are written, enabling recovery. A replicated log orders acknowledged entries across nodes and can protect shared state changes. Consensus explains how nodes agree on such entries. Event Sourcing, by contrast, stores domain events as the durable source of domain state. In the shop, a database WAL can restore stock data; by itself it provides neither replicated acknowledgement nor a domain event model.

For testingIn the shop, compare a database crash, the failure of a replica and the reconstruction of an order. For each case, indicate whether WAL recovery, confirmed log replication with Consensus or business event history with Event sourcing is responsible, and check the restart with suitable data.