If one candidate in-memory store keeps nothing across a restart by design and another offers a periodic copy and a write log, how should that change your design?
answer
- not two settings, two components
- reconstructible, or acceptable to lose
- persistence bounds a restart
- the window shrinks, never closes
- still never the only copy
basics
~20 sIt changes how big an empty restart is, not whether you need a system of record behind the tier. Either way, everything in the tier must be reconstructible or its loss must be acceptable; persistence only shortens and shrinks the restart.
solid answer
~50 sThe difference is real but narrower than it looks. With a store that keeps nothing, **every** restart is an empty restart: the keyspace is rebuilt entirely from the system of record behind the tier, so that system has to be able to absorb the resulting burst, and nothing may live in the tier that has no other home. With a store offering a copy and a log, restarts come back mostly populated and the burst is much smaller. What does **not** change is the rule that the tier is never the only copy: even with both postures, a write can be acknowledged to the caller and lost, so state with no other home is still exposed — just less often. Treating persistence as a licence to make the tier a system of record is the failure this comparison is asked to catch.
go deeper
The takeaway to hold on to is that neither store may hold the only copy of anything that matters. Persistence changes how much has to be rebuilt after a restart, not whether something else owns the data.
Be able to list what a keep-nothing store obliges — every restart empty, nothing without another home, the system behind sized for a full rebuild — and what the other store charges for avoiding that, on memory and on the write path.
This is production judgment: say which properties change, which are identical, and what you would actually choose on if both cleared the bar. Interviewers are checking whether you treat persistence as a licence or as a bound on restart size.
Note that this is a component choice, not a setting, so it is expensive to reverse once a fleet is on it. Weigh the simplicity of a store with no persistence against a durability property your design may never be allowed to rely on anyway.
## These are two different components, not two settings The framing matters. It is tempting to read this as "one has persistence switched on and the other has it switched off", but for a store that keeps nothing by design there is no switch. Persistence is absent from the product, not disabled in it. That makes the choice an architectural one you make when you pick the component, and it is much harder to reverse than a configuration change. So the honest way to answer is to describe what each one obliges the design around it to be true, and then to name what is identical in both cases. ## What a keep-nothing store obliges - **Every restart is an empty restart.** Not the unlucky ones — all of them, including planned ones. Deploys, host maintenance and version upgrades all produce the same event. - **Nothing may live there that has no other home.** State that exists only in the tier is state that a routine restart destroys. - **The system of record behind the tier has to be able to take the rebuild.** The traffic that the tier was absorbing lands on the system behind for as long as the tier is repopulating. - **In exchange, you get simplicity.** No write-path tax, no copy divergence, no growing log to compact, no disk to size, and a process that starts instantly. ## What a store with both keeping postures obliges - **You now have a posture to choose and to own**, including a flush policy and a copy interval, and a default you did not pick if you do not choose. - **You pay while serving**: memory as the live keyspace and a copy in progress diverge, latency on the write path from the log, and the periodic cost of replacing a grown log with a shorter one. - **You get a much smaller restart shock**: the process returns with most of its keyspace, so far less is rebuilt from the system behind and the tier reaches useful hit ratios sooner. - **You get a longer start.** Replay and loading take time; the process is unavailable while they run, which a keep-nothing store simply is not. ## What is identical in both cases This is the part interviewers listen for. | Property | Keep-nothing store | Store with both postures | |---|---|---| | Can hold the only copy of state | No | No | | Acknowledged write can be lost | Yes | Yes, in a smaller window | | Needs a system of record behind it | Yes | Yes | | Size of an empty-restart shock | Full keyspace | The part not restored | | Frequency of an empty restart | Every restart | Only when a copy is unusable | A write log narrows the window in which an acknowledged write disappears. It does not confer the kind of durability a storage engine offers, where the acknowledgement is the guarantee. That is the distinction the comparison exists to force: **persistence here bounds a restart; it does not promote the tier to a system of record.** ## When the difference does not matter If everything in the tier is a reconstructible copy of something that lives elsewhere, and the system behind can absorb a full rebuild at your traffic level, the two stores are close to interchangeable on this axis, and you should choose between them on other grounds entirely — the value shapes you need, the access cost, how the tier is distributed, what operating it costs. Teams routinely over-weight persistence in this comparison and under-weight everything else, because persistence is the property with the scariest failure story attached. ## When it matters a great deal It matters when the tier holds ephemeral state with no other home — the kind of state that is not a copy of anything — because then a restart is not a performance event but a correctness event. It also matters when the keyspace is large enough or the traffic heavy enough that a full rebuild would overwhelm the system behind. In both cases the right conclusion is often not "pick the store with persistence" but "stop putting that state here", because even the store with both postures has a window. ## How to say it in an interview Name the three things in order: what changes (the size and frequency of an empty restart), what does not change (the tier is not the only copy, and an acknowledged write can still be lost), and what you would actually decide on if both stores cleared that bar. An answer that treats a keep-nothing store as obsolete, or treats a write log as a durability guarantee, misses in opposite directions from the same misunderstanding.
- A team argues the store with a write log can safely hold session state with no other home. What is wrong with that?A log narrows the window in which an acknowledged write is lost; it does not close it. State with no other home that lands in that window is simply gone, and there is nothing to reconstruct it from. The fix is not a tighter flush policy but a decision about where that state actually lives, with the tier holding a copy rather than the original.
- What would make you choose the keep-nothing store even though the other one can persist?Everything in the tier being a reconstructible copy, the system of record behind it being able to absorb a full rebuild, and a preference for the simpler component: no write-path tax, no divergence during a copy, no log to grow and compact, no disk to size, and an instant process start. Simplicity you can defend beats a durability property you do not use.
- Does the keep-nothing store have any advantage at restart itself?Yes — it has no recovery time. There is nothing to load and nothing to replay, so the process is serving as soon as it is listening. A store restoring a large keyspace from a copy, or replaying a long log, is unavailable while it does that. The cost is simply moved: instant start, empty tier, and the rebuild happens under live traffic.
saying these in an interview costs you the question
- Calls a store with no persistence obsolete rather than a deliberate design
- Says a write log makes the tier safe to hold state with no other home
- Believes persistence removes the need for a system of record behind the tier
- Assumes the two stores are interchangeable because both survive a restart
- Thinks the choice only affects restart, not what you put in the tier