In a model that refreshes prerendered pages out of band, what can a request for a path with no stored copy be given?
answer
- the fallback has no fallback
- nothing old means nothing to serve
- wait for a first render, or send a placeholder
- steady state is identical either way
basics
~20 sWith nothing stored there is no stale copy to serve. Frameworks take one of two routes: hold the request for a first render and store its output, or answer immediately with a placeholder while the render runs out of band.
solid answer
~50 sServing stale presupposes something old to serve, and on a path that has never been rendered there is nothing. So the model has to fall back to one of two behaviours. It can **hold the request**, render the path there and then, store the result and answer with it — the first visitor pays full render latency, and everyone after them is served from storage. Or it can **answer at once with a placeholder** — a shell or a loading state — and let the render happen out of band, so the real page becomes available to later requests. A third possibility is not to create a copy at all: a path outside the set the framework is willing to render is refused with a not-found response. Which of these you get is a framework and configuration choice, and it is worth knowing which one your system makes, because they have very different first-visit characteristics.
go deeper
Remember why this case is different: the trick of serving an old copy needs an old copy to exist. On a path that has never been rendered, the visitor either waits for a render or gets a placeholder first.
Name both fallbacks and the property that distinguishes them — first-visit latency versus a first response that lacks the content — and note that after the first render both converge on the same behaviour.
Bring in what reads the first response. Crawlers and link previews often see a page once, which makes the placeholder route a content decision, not only a latency one, and makes the empty-store case worth rehearsing.
Decide it per surface rather than globally, and be explicit about who absorbs the first render: your visitor, your crawler, or your data source during a cold start after a restart.
## Why a missing copy is a different case The defining behaviour of this model — answer from storage, refresh beside it — has a precondition: **something must be in storage**. When a request arrives for a path with no stored output, that precondition fails. The framework cannot serve stale, because nothing is stale; it has to decide, at that moment, what a visitor gets. This case is more common than it sounds. It occurs on a path whose output was never produced ahead of time, on a path created after publication, and after any event that leaves the storage holding copies empty. ## The two answers | | Hold the request | Answer immediately | |---|---|---| | What the first visitor gets | the real page, after a full render | a placeholder, then the real page on a later request | | First-visit latency | the cost of data access plus render | that of a stored document | | What a one-shot reader sees | correct content | content that is not the page | | Risk if the render is slow | a visibly slow first visit | a fast response that is not useful yet | | Effect on later visitors | none — they are served from storage | none — they are served from storage | Both converge on the same steady state: after the first render lands, the path behaves like any other stored page, and the question stops arising. ## What each choice costs - **Holding the request** makes the first visit indistinguishable from rendering inside the request, including its dependence on the data source being up. If that source is slow or down, the first visitor sees it. - **Holding the request** also means a burst of first visitors to one path all wait for the same work, which is why implementations that hold typically let one render serve all of the waiting requests rather than starting one per request. - **Answering immediately** protects latency but sends HTML that does not contain the page's content. Anything that reads the response once — a crawler, a link preview, a scraper — records the placeholder rather than the page. - **Answering immediately** also complicates the genuinely-missing case: if the render concludes that the path has no content, the placeholder has already been sent with a success status, and the correction has to happen after the fact. - **Refusing outright** is the cheapest and the most predictable, and it is the right answer for paths that should not exist. Deciding *which* paths are eligible is a separate design question from what an eligible-but-unstored path receives. ## The cold-storage case The same branch runs for every path at once when the store holding copies starts out empty. Until each path has been requested and rendered once, the site behaves like whichever fallback the framework chose: either a wave of slow first visits or a wave of placeholder responses. Two consequences follow: 1. The first minutes after a fresh start are not representative. Measuring latency or origin load then tells you about first renders, not about steady-state serving. 2. Whether that happens at all depends on where the refreshed output is kept and how long it survives — the design of that store, and of any layer in front of it, is a deployment concern rather than a property of the rendering model. ## Where frameworks differ This is one of the places where frameworks genuinely diverge, and an honest answer says so. Some hold the request for a first render by default and treat the placeholder route as opt-in; others do the reverse; some refuse any path that was not declared in advance, so the unstored case never arises for them at all. Some let the choice be made per route, which is usually the right capability to have: a marketing page can afford to hold a request for a correct first render, while a page reached mainly by navigation inside the app can afford a placeholder because the visitor is already looking at something. ## How to answer it in an interview Lead with the reason the case is special — there is no old copy, so the stale-while-refreshing answer does not apply — then name both fallbacks and the property that separates them: whether the first visitor waits or the first response is incomplete. Finish by saying which one you would pick for the surface in question and why. That ordering shows the mechanism first and the judgment second, which is exactly the shape interviewers score well.
- Which fallback is safer for a page that search crawlers reach directly?Holding the request. A crawler typically records what the first response contained, so a placeholder can be indexed as the page's content. Paying render latency once, on a visit that only happens before the copy exists, is usually the cheaper mistake than publishing an empty shell to whatever reads the page once.
- What happens on the second request for that path?It is served from storage like any other prerendered page, because the first render's output was stored. From that point the path follows the normal cycle: stored copy answers requests, refreshes happen out of band. The unstored branch is a one-time cost per path, not a recurring one.
saying these in an interview costs you the question
- Thinks an unstored path is always answered with not found.
- Assumes a stale copy exists for every path by definition.
- Says the first visitor never waits, whatever the framework does.
- Treats a placeholder response as equivalent to the real page.
- Believes a path must be known before publication to be renderable.