Operations, Security & Reliability
Replication and Read Scaling
Replication maintains additional copies by shipping physical changes or logical data operations; topology, acknowledgement policy, lag, conflicts, and routing determine durability and read semantics, while independent backups remain necessary.
- Physical and logical replication copy different abstractions.
- Synchronous and asynchronous describe acknowledgement, not freshness forever.
- Lag has several stages.
- Read replicas weaken session expectations unless routing repairs them.
- Replicas have conflicts and backpressure.
- Replication is not backup.
| Choice | Benefit | Failure/semantic cost |
|---|---|---|
| Physical async standby | low primary wait; close copy | recent acknowledged loss and stale reads |
| Physical sync standby | stronger configured durability evidence | write latency; unavailable acknowledgement set can stall/fail writes |
| Logical subscriber | selective data/version flexibility | DDL/sequence/identity/conflict management |
| Read routing | offloads eligible reads | staleness, monotonicity, replica conflict |
| Delayed replica | time to notice destructive writes | not immutable; operational lag and promotion complexity |
commit write on primary -> receive durable commit position token L
for a dependent read:
if chosen replica visible_position >= L: read replica
else wait only within request freshness budget
if budget expires: route primary or return explicit stale/unavailable result
never infer freshness from wall-clock delay alone
record route, required position, observed position, and wait duration