An in-memory tier keeps a write log flushed on a one-second timer, plus a copy every five minutes — what is the loss window?

## Two intervals, one of which governs This configuration is the common both-postures pairing: a **write log** appended on every write and flushed to disk on a timer, and a **point-in-time copy** of the keyspace taken every five minutes. Candidates reach for the larger number because a five-minute copy is the more visible artefact, but in normal operation the copy interval is not the window at all. The reason is what each artefact contains. The copy is a whole image of the keyspace at the instant it was taken. The log carries every write acknowledged since then, in order. So as long as the log is intact, restoring means loading a base state and replaying the log forward to the last flushed byte. The only writes with nowhere to come from are the ones that were acknowledged to callers but had not yet been flushed to disk — the tail bounded by the flush timer. **The sentence: we may lose up to about a second of acknowledged writes.** ## Why "about", and not "exactly one second" ``` 0.00s a caller sends a write; the store applies it in memory 0.00s the store appends the write to the write log and acknowledges the caller 0.97s the last flush to disk completes 1.40s the process is killed on restart, the writes between 0.97s and 1.40s are gone that is 0.43s of acknowledged writes on this occasion, not a full second ``` The timer bounds how long a write can sit unflushed, so a typical crash costs less than the timer and the worst case sits at or slightly past it — a flush that has begun still has to complete, and a machine under memory or disk pressure can stretch it. That is why the sentence says *up to*. One thing to check rather than assume: **where the acknowledgement sits relative to the flush varies by store.** In this posture the caller is told the write succeeded before the bytes are flushed, which is what creates the window. Other stores acknowledge only after the flush, and some let an individual call ask for that. The window is a property of the configuration in front of you, not of the category. ## What the copy interval actually buys The five-minute copy is doing three other jobs, none of which is "the window": - it gives a **bounded base state**, so replay at start does not have to walk a log that goes back to process start — which is what keeps recovery time in minutes rather than hours; - it bounds how large the log grows before compacting the write log is worthwhile, which is a separate cost; - it is the **fallback** when the log cannot be used. That last one is the branch worth naming in an interview. If the log is truncated at a bad point, unreadable, or the store is started against the copy alone, the sentence changes: *we may lose up to five minutes of acknowledged writes, plus the time the copy itself took to write* — because a copy taken over thirty seconds is current as of when it began, not when it finished, on stores that write the copy from a frozen view of the keyspace as writes continue. ## Turning the sentence into records Seconds are not a currency anyone outside engineering can price. Multiply: 1. Take the window in seconds, at its worst case. 2. Multiply by the acknowledged write rate at the **busiest** minute of the day, not the average. 3. Say what those records are. At four thousand writes a second, a one-second window is roughly four thousand acknowledged writes. Whether that is fine or unacceptable depends entirely on what they are: four thousand refreshed view counts is nothing; four thousand records that say "this request has already been handled" is a real incident. ## The costs on the other side of the trade Naming the window is half the job; the other half is what keeping it that small costs while the tier is serving. | Lever | Effect on the window | What it costs | |---|---|---| | flush on every write | smallest window available | a flush on the write path for every operation | | flush on a timer (about a second) | roughly the timer | little on the write path | | leave flushing to the operating system | unbounded by anything you control | nothing you pay for directly | | shorter copy interval | shortens only the fallback window | divergence between the copy and the live keyspace, paid more often | That last row is the one candidates skip. Taking a whole copy of a live keyspace is not free: while the copy is being written the serving process keeps accepting writes, and the memory the live keyspace and the copy diverge by grows with write rate times copy duration. Halving the copy interval does not halve anything important here, because the everyday window is set by the flush timer — it just pays that divergence twice as often. ## The judgement the question is really after A strong answer ends by saying what the window is *for*. This configuration bounds a restart and keeps recovery time survivable; it does not make the tier a durable system of record. If a second of acknowledged writes is genuinely unacceptable for some of this data, the answer is not to keep shaving the flush timer — it is that this data should be written to a durable system of record first, with the tier holding a copy that can be rebuilt.