Your stream is copied asynchronously to a second cluster — why can the recovery point you state for it never be smaller than the copy lag?
answer
- the hop is asynchronous by construction
- the copier starts after the acknowledgement
- acknowledged on one cluster only
- copy lag is the loss window
- zero needs a synchronous cross-site write
basics
~20 sThe asynchronous copy hop sets the floor. Records acknowledged on the source cluster but not yet carried to the target exist in one place only, so losing the source loses them — the recovery point is at least the copy lag.
solid answer
~50 sA recovery point is the largest loss you are willing to state. For a stream fed to a second cluster by a cross-cluster copier, that loss is the **uncopied tail**: the records the copier had read from the source but not yet written into the target when the source was lost. The copier sits outside the producer's write path — the source cluster acknowledges a write on its own terms and the copier learns about it afterwards — so there is always a span of acknowledged records that exists on exactly one cluster. Tuning the copier moves the copy lag between the two clusters and therefore moves the floor, but no setting puts the floor below the lag actually achieved. Only refusing to acknowledge a write until both sites hold it reaches zero, and that is a different and much more expensive arrangement.
go deeper
Recall that a cross-cluster copy is asynchronous, so the target is always slightly behind. Whatever was accepted on the source in that gap exists in one place only, and that gap is the number you promise.
Explain where the gap comes from: the copier reads after the source cluster has already acknowledged the write, so the copy hop's own latency is the floor. Say which unit you are promising in — records or seconds of copy lag.
Show that you state the ceiling against worst-case lag, not steady state, and that you know which streams carry facts recoverable from elsewhere. Say what the lever actually is: reduce the lag, or pay for a synchronous write.
Frame it as a purchase. Sub-second lag and a synchronous cross-site write cost very different money and very different availability, and the right answer differs per stream. Decide which streams are worth which posture, and put the number in writing.
## What a recovery point means when the thing at risk is a stream A **recovery point** is a ceiling: the largest amount of data you are willing to say out loud that you could lose when a cluster is gone. For a stored dataset the ceiling is usually expressed as time since the last durable copy. For a stream kept on a second cluster by an ongoing **cross-cluster copier**, the honest unit is different. What you lose is the **uncopied tail** — the records that existed on the source cluster and had not reached the target cluster when the source was lost. Stated as a number, that is either a count of records or the **copy lag between the two clusters**, in seconds. This is not a backup number and it does not come from a schedule. It comes from a pipeline that is running continuously and is always a little behind. ## Why the copy hop sets the floor A **copy hop** is one directed source-to-target link. The copier reads records from the source cluster and writes the same records into the target cluster. That round trip costs real time: a read, a network crossing, a write the target must make durable, and whatever queueing sits between those steps. Crucially, none of that is inside the producer's write path. A writer is told its record was accepted by the **source cluster**, on the source cluster's own durability terms, and the copier finds out about the record only afterwards. Two consequences follow, and together they are the whole answer: - Every record acknowledged to a writer within the last *lag* seconds exists on exactly one cluster. If that cluster is lost, those records are lost with it — there is no second place holding them. - Tuning the copier changes the lag, and therefore changes the floor, but the floor is always *the lag*. More copier capacity, a shorter or fatter link, or fewer streams per hop can take seconds down to sub-second. None of them takes it to zero, because the copier can only start work after the write has already been accepted somewhere. ## The two units, and why the choice matters | Unit | What it answers | Where it misleads | |---|---|---| | Seconds of copy lag | How much wall-clock time of production is at risk | A quiet stream can show seconds of lag and almost no records; a bursty one can put a hundred thousand records at risk in two seconds | | Records not yet carried | How many business facts are at risk | Says nothing about how far back in time the gap reaches, which is what you need to reconcile against a source system | | Timestamp of the newest copied record versus now | The lag measured at the target, without trusting the copier's own report | Depends on which clock stamped the record; a writer's clock and a broker's clock are not the same | Platforms expose this differently. Some publish a lag figure per copy hop; some let you compute it only by comparing the newest record on each side; a rented cluster may expose one number for an entire hop and nothing per stream. Where you can, state the target in **both** units and say plainly which one the promise is made in. ## What genuinely lowers the floor, and what it costs 1. **Reduce the achieved lag.** More copier capacity, a shorter path, fewer streams competing on one hop. This moves the floor down and is usually the cheapest lever — but it never reaches zero, and it degrades exactly when you need it (a saturated link, a burst, a copier restart). 2. **Make the write synchronous across sites.** The only route to a genuine zero. The writer is not told the write succeeded until both sites hold it. You pay a cross-site round trip on *every* write, and when the far site is unreachable you must choose between refusing writes and quietly dropping back to asynchronous — which puts the floor straight back without telling anyone. 3. **Keep the record somewhere else at write time.** Publishing to a writer-side store that can re-emit does not lower the stream's recovery point at all; it changes what the loss *costs*, which is a different and often better conversation. ## Where this question is usually failed - **Answering with a backup schedule.** A file backup taken nightly is a far worse number than an ongoing copy, and it is not the number in play once a copy hop exists. - **Quoting steady-state lag as the target.** The stated ceiling has to cover the worst lag — a copier restart, a saturated link, a traffic burst, a slow target cluster — not the median on a calm afternoon. - **Confusing copy lag with reader lag.** How far the target cluster trails the source is a property of the hop. How far a consumer trails the newest record is a property of that consumer, and it has nothing to do with this number. - **Assuming the loss announces itself.** Readers that resume on the target cluster see a continuous stream; nothing reports a hole where the uncopied tail should have been.
- What would it actually take to make a stream's recovery point genuinely zero?Writers must not be told a write succeeded until both sites hold it — a synchronous cross-site write. You pay the cross-site round trip on every write, and when the far site is unreachable you must either refuse writes or fall back to asynchronous, which restores the loss window. Most organisations decline the trade and state a loss window instead.
- Copy lag between the two clusters sits steadily at two seconds, but the stated ceiling is thirty. Is that number wrong?No. The target is a ceiling you must be able to honour on a bad day, not a report of the median. Copier restarts, a saturated link, a traffic burst or a slow target cluster all push lag well past steady state, and the switch tends to happen precisely when something is already wrong.
- Does adding a third cluster, fed by its own copy hop, improve the recovery point?Not by itself. Each hop has its own lag, and the loss window for any one target is that target's lag. A third site improves the odds that *some* copy survives a correlated failure, and it can lower the loss if you switch to whichever target is furthest ahead — but the floor for each remains its own copy lag.
A courier collects outgoing mail from your office every few minutes. Anything written since the last collection exists only in your building, so if the building burns that is exactly what is lost. Hiring a faster courier shrinks the window; it never closes it. The only way to lose nothing is to refuse to call a letter sent until the recipient has it in hand — and then you wait for them on every single letter.
saying these in an interview costs you the question
- Says a nightly file backup schedule sets the recovery point
- Claims a faster copier makes the recovery point zero
- Promises a zero loss window without a synchronous cross-site write
- Confuses copy lag between clusters with how far a consumer trails
- Quotes calm-afternoon lag as the stated ceiling
- Assumes the lost tail shows up as an error somewhere