While a whole copy of a live keyspace is being written, what can happen to resident memory, and what determines the size of that effect?

## Why taking a copy costs memory at all A **point-in-time copy** has to represent the keyspace at one instant, and the store is not allowed to stop serving for the minutes it takes to write that instant out. Those two requirements collide: whatever a caller changes after the cut must not appear in the copy, yet the pre-change value must survive long enough for the copy to record it. The store therefore holds, for the duration of the write, **two versions of everything that changed since the cut**. That separation between the copy's image and the live keyspace is the **divergence**, and it is paid for in memory. ## The quantity that sizes it The intuition most candidates reach for — "the copy duplicates the keyspace, so memory doubles" — is the wrong model. What has to exist twice is not the keyspace; it is the part of the keyspace that **moved** while the copy was being written: - **Write rate × copy duration** is the first-order term. A tier absorbing changes to 200 MB of distinct data per minute, copied over four minutes, diverges on the order of 800 MB — not on the order of its total size. - **Distinct regions, not write count.** Hammering the same hot key ten thousand times diverges that region once. A workload that spreads thin writes across the whole keyspace is far more expensive than one with the same operation rate concentrated on a few keys. - **Capped by the keyspace size.** You cannot diverge by more than everything; a copy taken while the whole keyspace is overwritten approaches, but does not exceed, a second copy in memory. - **Released when the write ends.** Once the copy's file is closed the store no longer needs the old versions and the extra memory comes back — it is a spike bounded by the copy, not a permanent tax. ## Where keyspace size actually enters Size does matter, but through the **duration**, not directly. Writing the keyspace out takes time roughly proportional to how many bytes there are and how fast the device swallows them, and the longer that takes, the more time divergence has to accumulate at the workload's write rate. That is why the two inputs have to be considered together: | Keyspace | Write rate during the copy | What divergence costs | |---|---|---| | Large | Low | Long write, little changing — cheap, despite the size | | Small | High | Short write bounds it; capped by the small keyspace anyway | | Large | High | Long write and heavy change — the ruinous combination | | Large | High but concentrated on few keys | Much cheaper than the raw operation rate suggests | ## The mechanism varies; the cost class does not Stores in this class reach the same guarantee by different routes, and a strong answer says so rather than reciting one: - Some give the writing side an unchanging view of memory — in some stores a child process does the writing — and the operating system keeps the pre-change version of each region the serving side touches. - Some maintain **incremental checkpoints**, versioning regions as they change, which converts the spike into a smaller steady overhead and more background work. - Some write from a structure that already keeps versions for other reasons, so the copy is close to free in memory and paid for elsewhere. What none of them can do is present one instant to the copy while callers change the data underneath, for free. ## When the spike becomes an outage The reason this is asked at interview is that the failure is abrupt rather than gradual: 1. The tier is sized so its keyspace fits the machine with modest headroom. 2. A copy is cut during peak write traffic, and divergence starts climbing on top of the keyspace. 3. The machine runs out, and either it begins swapping — at which point in-memory operations become device operations and latency collapses — or the operating system kills the process outright. 4. The process comes back and restores from the previous copy, so the cut that was in progress bought nothing. The pathological case is a copy taken at exactly the moment the tier is least able to afford it. How much headroom a tier should carry is a capacity question of its own; what belongs here is knowing that the copy's demand is real, is transient, and scales with change during the write. ## What to volunteer Say what drives the number (write rate times copy duration, distinct regions, capped by size), say that the mechanism differs by store, and say how you would check it: watch peak resident memory during copy windows, not the average between them, and correlate it with measured copy duration rather than with the configured schedule.