Learning goal: decide when a data replica delivers a necessary architectural property and when it merely adds cost and risk.
Which property are we trying to achieve?
A replica may offload reads, reduce distance to data or support an alternate service path. A copy is not automatically high availability: without tested application failover it may not shorten an outage. It is not a backup either: erroneous updates and deletions can propagate.
| Option | Appropriate when | What to verify |
|---|---|---|
| A. No replica; optimise the source | Poor queries, indexing or needless reads cause the bottleneck. | Do measured latency and throughput meet objectives without another copy? |
| B. Read-only replica | Reporting reads compete with transactional workloads. | What replication lag is acceptable? How will read-after-write and failures work? |
| C. Failover replica | Recovery objectives justify another node or site. | How will failure detection, split-brain prevention, promotion and failback be tested? |
Neither B nor C is the default. Without measurable demand and recovery objectives, define acceptance criteria before adding a database. Better indexes, a carefully governed cache or an asynchronous reporting pipeline might be suitable alternatives, each with distinct consistency and operations trade-offs.
Evidence gate
Before approval, record baseline workload, freshness requirements, consistency expectations, RPO/RTO, failover design, data scope and retention, and operational cost. Measure replication lag under load and rehearse failover and return. Queries requiring authoritative current state should use the source of truth.
Related reading: RPO/RTO recovery drill, conditional approval, SLO and error budgets.
Discuss this article
Share a constructive observation or an anonymised example. Comments are checked by AI before publication. Uncertain cases go to the moderator.