An outlet retracts a story already live in a news feed - at which stage of the funnel do you enforce the takedown?

seniormust knowfreq 63%

answer

the index rebuilds too slowly to promise anything
check the final slate, every request
a small list, a local read
cached slates hold the wrong answer
late check guarantees, upstream removal optimises

basics

~20 s

At the last stage before the response: a suppression check against the final slate, reading a takedown list from a low-latency key-value store on the serving path. Removing the article upstream is also right, but candidate sources and precomputed slates refresh too slowly to be the guarantee.

solid answer

~50 s

Enforce it late, and enforce it upstream too - the two are doing different jobs. The late check is the guarantee: every response passes its final slate against a suppression list held in a low-latency key-value store replicated to each serving region, so the article disappears within one request of the takedown landing. The upstream removal - dropping it from the candidate sources and any index - is the optimisation, and it arrives on a build or refresh cadence of minutes to hours, which is far too slow to be relied on alone. The late check needs three supports: over-fetch, so a shortened slate does not appear; a version stamp on the suppression list mixed into any cached-slate or prediction-cache key, so already-cached responses cannot serve the retracted item; and a log line naming the rule that removed it.

Enforce it **late, and enforce it upstream too** - the two are doing different jobs. The late check is the guarantee: every response passes its final slate against a suppression list held in a low-latency key-value store replicated to each serving region, so the article disappears within one request of the takedown landing. The upstream removal - dropping it from the candidate sources and any index - is the optimisation, and it arrives on a build or refresh cadence of minutes to hours, which is far too slow to be relied on alone. The late check needs three supports: over-fetch, so a shortened slate does not appear; a version stamp on the suppression list mixed into any cached-slate or prediction-cache key, so already-cached responses cannot serve the retracted item; and a log line naming the rule that removed it.

go deeper

for a junior

Remember that an article can be deleted at its source and still be served, because slates and indexes built earlier already contain it.

for a middle

Explain the split: a per-request membership test against a small suppression list is the guarantee, while removing the item upstream saves the slot but arrives on a build cadence.

for a senior

Show the supporting machinery you would actually build - regional replication with a known propagation delay, a list version in the cache key, over-fetch, and a logged removal reason.

for a principal

State the takedown as a commitment with a number attached, and make sure one lever enforces it across every surface rather than one path per team.

Two places you can enforce it, doing two different jobs

A takedown can be applied at the candidate sources or at the end of the serving path, and the design-round answer is that you do both, for different reasons.

	remove upstream	suppress on the serving path
where	candidate sources, the retrieval index, any precomputed slate	the last pass before the response
propagation	one index build or refresh - minutes to hours	the next request
covers cached responses	no, an already-written slate still holds it	yes, if the cache key carries the list version
cost per request	none	one lookup against a small set
what it buys	the slot is not wasted on a doomed candidate	the guarantee that it is not shown

The late check is the guarantee; the upstream removal is the optimisation. Reversing those two is the mistake the question is testing for.

Why the late check has to be last

Three properties force it to the end of the funnel:

Every path converges there. Candidates arrive from several sources, some of them precomputed hours ago. A check placed at one source misses the others.
It must beat the refresh cadence. Index builds and precomputed slates are the reason an item survives its own deletion; the check that runs per request does not care when the index was built.
The list is small and the check is cheap. Suppressions number in the thousands, not the millions, so a membership test against a set held in a low-latency key-value store - or a compact probabilistic filter in front of it, with a confirming read on a hit - costs microseconds against a budget measured in tens of milliseconds.

What the late check needs around it

Replication to every serving region. A takedown that reached three regions out of four is not a takedown. This usually means the write is fanned out and the read is local, and it means you should know your propagation delay as a number.
A version stamp mixed into cache keys. Any cached slate or cached prediction produced before the takedown is a copy of the wrong answer. Stamping the suppression list's version into the key retires those copies at the moment the list changes; the alternative, waiting for a time-to-live to expire, is exactly the delay you were trying to avoid.
Over-fetch. The check is subtractive. A shortlist sized to the page produces a page one item short; the funnel already over-fetches for de-duplication, and this rides on the same budget.
A logged reason. Record which rule removed which item on which request, or nobody can answer why a story vanished from a slate.

The same path serves the rest of the eligibility rules

A retraction is the urgent case, but this check is the same machinery as:

Region and licence rules - an article that may not be served outside the publishing region, evaluated against the request's region rather than the item alone.
Paywall state - eligible to show, or eligible only in a reduced form, depending on the reader's entitlement.
Must-carry - the inverse edit, where an editorial pin forces an item into a slot regardless of its relevance score.
Safety suppressions - content withdrawn for reasons that have nothing to do with the outlet.

Because they share the path, they need a stated precedence: a deny from a legal or safety rule has to beat a must-carry pin, or one urgent edit can be cancelled by another.

What breaks if you rely on upstream removal alone

The retracted article keeps appearing for the length of one index build, and longer for anyone served a cached slate.
Precomputed slates written before the takedown serve it until their time-to-live expires, with no trace in the request path of why.
A source you forgot - a popularity fallback list, an editorially curated set - keeps supplying it after the main index dropped it.
The incident has no single lever. The only honest answer to "is it gone yet" becomes "probably", which in a retraction is not an answer.

The last bullet is the one that matters in a design round. A takedown is an operations action with a stated latency, and the architecture is what lets you state it.

## Two places you can enforce it, doing two different jobs A takedown can be applied at the candidate sources or at the end of the serving path, and the design-round answer is that you do both, for different reasons. | | remove upstream | suppress on the serving path | |---|---|---| | where | candidate sources, the retrieval index, any precomputed slate | the last pass before the response | | propagation | one index build or refresh - minutes to hours | the next request | | covers cached responses | no, an already-written slate still holds it | yes, if the cache key carries the list version | | cost per request | none | one lookup against a small set | | what it buys | the slot is not wasted on a doomed candidate | the guarantee that it is not shown | **The late check is the guarantee; the upstream removal is the optimisation.** Reversing those two is the mistake the question is testing for. ## Why the late check has to be last Three properties force it to the end of the funnel: - **Every path converges there.** Candidates arrive from several sources, some of them precomputed hours ago. A check placed at one source misses the others. - **It must beat the refresh cadence.** Index builds and precomputed slates are the reason an item survives its own deletion; the check that runs per request does not care when the index was built. - **The list is small and the check is cheap.** Suppressions number in the thousands, not the millions, so a membership test against a set held in a low-latency key-value store - or a compact probabilistic filter in front of it, with a confirming read on a hit - costs microseconds against a budget measured in tens of milliseconds. ## What the late check needs around it 1. **Replication to every serving region.** A takedown that reached three regions out of four is not a takedown. This usually means the write is fanned out and the read is local, and it means you should know your propagation delay as a number. 2. **A version stamp mixed into cache keys.** Any cached slate or cached prediction produced before the takedown is a copy of the wrong answer. Stamping the suppression list's version into the key retires those copies at the moment the list changes; the alternative, waiting for a time-to-live to expire, is exactly the delay you were trying to avoid. 3. **Over-fetch.** The check is subtractive. A shortlist sized to the page produces a page one item short; the funnel already over-fetches for de-duplication, and this rides on the same budget. 4. **A logged reason.** Record which rule removed which item on which request, or nobody can answer why a story vanished from a slate. ## The same path serves the rest of the eligibility rules A retraction is the urgent case, but this check is the same machinery as: - **Region and licence rules** - an article that may not be served outside the publishing region, evaluated against the request's region rather than the item alone. - **Paywall state** - eligible to show, or eligible only in a reduced form, depending on the reader's entitlement. - **Must-carry** - the inverse edit, where an editorial pin forces an item into a slot regardless of its relevance score. - **Safety suppressions** - content withdrawn for reasons that have nothing to do with the outlet. Because they share the path, they need a stated precedence: a deny from a legal or safety rule has to beat a must-carry pin, or one urgent edit can be cancelled by another. ## What breaks if you rely on upstream removal alone - The retracted article keeps appearing for the length of one index build, and longer for anyone served a cached slate. - Precomputed slates written before the takedown serve it until their time-to-live expires, with no trace in the request path of why. - A source you forgot - a popularity fallback list, an editorially curated set - keeps supplying it after the main index dropped it. - The incident has no single lever. The only honest answer to "is it gone yet" becomes "probably", which in a retraction is not an answer. The last bullet is the one that matters in a design round. A takedown is an operations action with a stated latency, and the architecture is what lets you state it.

Why does a precomputed slate make this harder than a live-scored one?
Because the decision was made before the takedown existed and is already written down. The serving path only reads it, so a suppression check on the stored slate is the sole thing standing between the retraction and the reader. Mixing the suppression list's version into the cache key retires those stored slates immediately instead of waiting out a time-to-live.
How do you keep this check from shortening the page?
Over-fetch. The shortlist entering the list-editing pass is sized several times the slot count precisely because every rule in that pass is subtractive - de-duplication, quotas and suppressions all remove candidates. The page is then filled from what survives, and only an unusually large removal reaches the point where the slate runs short.
What decides the outcome when a must-carry pin and a suppression rule name the same article?
A stated precedence between rule classes, with the deny winning. Legal, safety and licence rules are evaluated as hard eligibility before any promotion is applied, so a pinned item that is also suppressed is simply not eligible to be pinned. Leaving that order implicit means the winner depends on which rule happens to be evaluated last.

A recalled item is pulled from the warehouse, but the promise that nobody receives one is the check at the packing bench, where every order passes regardless of which shelf it came from.

saying these in an interview costs you the question

Says removing the article from the index is enough on its own
Believes the ranking model will learn to stop showing retracted stories
Forgets that cached and precomputed slates still hold the item
Applies the check at one candidate source and calls it done
Cannot state how long the takedown takes to reach every region
Lets a must-carry pin override a legal suppression

An outlet retracts a story already live in a news feed - at which stage of the funnel do you enforce the takedown?

§ answer

basics

solid answer

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two places you can enforce it, doing two different jobs

Why the late check has to be last

What the late check needs around it

The same path serves the rest of the eligibility rules

What breaks if you rely on upstream removal alone

▾common follow-ups3 questions

▾analogy~10 s

▾red flags6 flags

Two places you can enforce it, doing two different jobs

Why the late check has to be last

What the late check needs around it

The same path serves the rest of the eligibility rules

What breaks if you rely on upstream removal alone

answer

go deeper