A team plans to start cleanup work the moment an entry's deadline passes by subscribing to the store's expiry announcements — what will they hit?
answer
- named for the deadline, fired at the reclaim
- late by an unbounded amount
- best-effort, nothing kept for absentees
- an accelerator, never the trigger
basics
~20 sAnnouncements fire when the entry is reclaimed, not when its deadline passes, so they arrive late by an unbounded amount. Where a store emits them at all they are best-effort, so a listener that is disconnected simply misses them.
solid answer
~50 sTwo independent problems, and the first surprises people more. An announcement is emitted at **reclaim**, not at the deadline — so it arrives whenever a caller touches the entry, a sweep samples it, or the store needs the room, which on an unread entry can be arbitrarily long after the deadline. "The moment the deadline passes" is not available at all. The second problem is reliability: where a store emits announcements, they are typically best-effort to whoever happens to be listening. A listener that is restarting, briefly disconnected or slow gets nothing and has nothing to go back for; a store may emit nothing at all; and on a replicated tier, which copy does the reclaiming and the announcing differs between stores. The safe design treats an announcement as a hint that may speed things up, and drives anything that must actually happen from a record of the work itself.
go deeper
Note the key fact: a store's notice about an expired entry is sent when the entry is actually reclaimed, which is later than the deadline and not at a predictable time.
Explain both defects together — unbounded lateness because it is tied to reclaim, and best-effort delivery to whoever is listening at that instant.
Apply the design test: ask what breaks if the notice never arrives, and move anything that matters onto a trigger that finds its own work.
The stance to hold is that a volatile tier's notices are an optimisation surface, not a contract surface, and that letting a team wire a business obligation to one is the decision to catch in review.
## What an announcement actually announces Some stores in this class can emit something when an entry goes away — an **expiry announcement**. The name invites a misreading. It does not say "this entry's deadline has passed"; it says "this entry has just been reclaimed", and those are different moments separated by an interval nobody controls. The entry is reclaimed when a caller touches it, when a background sweep samples it, or when the store needs its room. For an entry that nothing reads, on a store whose sweep is sampled, the announcement can follow the deadline by an unbounded interval. So the requirement as stated — start work *the moment* the deadline passes — cannot be met by this mechanism at all. A design that says "within a second of the deadline" is not tight; it is unimplementable this way. ## The second problem: it is a hint, not a guarantee Even setting timing aside, an announcement is not a promise that the message arrives: - **It is typically emitted to whoever is listening at that instant.** Nothing is kept for a listener that is not there. - **A listener that restarts, redeploys, drops its connection or falls behind gets nothing**, and there is nothing to go back and collect afterwards. - **A store may emit nothing at all.** Several stores in this class have no announcement mechanism, and where one exists it is frequently off by default because emitting costs work on the serving path. - **On a replicated tier, which copy reclaims and which copy announces differs between stores.** A listener attached to the wrong copy may see a different stream, or none. Put the two together and the honest description is: *a best-effort notice, at an unpredictable time after the deadline, that may never come*. ## What this means for the design The test to apply is simple: **what happens if the announcement never arrives?** | if the answer is | then | announcement's role | |---|---|---| | nothing is lost, just slower | the design is sound | an optimisation | | money, a resource or a contract is affected | the design is broken | must not be the trigger | | the system silently drifts | the design is broken, quietly | must not be the trigger | For anything in the lower two rows, the trigger must come from something that still exists when the notice does not. In practice that means the pending work is **recorded somewhere the cleanup can find on its own** — a record it can scan and act on — with the announcement, if it exists, used only to act sooner than the scan would. ## The pattern that works 1. **Write down the work, not just the entry.** If a deadline passing implies an action, the action needs a durable record of its own; the disappearing entry is not that record. 2. **Make the cleanup able to find its own work.** A pass that discovers what is due from the data is correct whether or not any notice arrives. 3. **Let the announcement only accelerate.** Treat it as "you may be able to act now rather than at the next pass", never as "this is your only chance to act". 4. **Make the action safe to run twice.** Once acting is driven by both a notice and a pass, the same work may be triggered twice, so it must be harmless to repeat. ## Why the misconception is so common It comes from reading the deadline as an event. A deadline feels like something that *happens* at a time, and a mechanism named for expiry seems like the callback for it. The store's model is the opposite: the deadline is a condition that becomes true silently, and every mechanism attached to expiry — the reclaim, the memory returning, the announcement — hangs off the later, opportunistic moment when the store gets around to acting on it. A candidate who says that plainly has understood the whole category, because it is the same separation that explains why memory does not come back on time either.
- How late can an expiry announcement be, in the worst case?Unbounded. It is emitted at reclaim, and reclaim happens when a caller touches the entry, a sampled sweep reaches it, or the store needs the room. An entry nothing reads, on a tier under no pressure, can sit dead indefinitely and announce nothing the whole time.
- If announcements are unreliable, is there any legitimate use for them?Yes, as an accelerator on a design that is already correct without them. A cleanup that finds its own work on a schedule can act earlier when a notice happens to arrive. The rule is that losing every notice must cost latency only, never correctness, and that acting twice must be harmless.
- Does turning the feature on cost anything?It is work on the serving path: the store does extra work at reclaim time to emit, and that work scales with how many entries are being reclaimed. Stores that offer it commonly ship it disabled for that reason, and the cost is worth checking before enabling it on a busy tier.
saying these in an interview costs you the question
- Expects the announcement at the deadline rather than at the reclaim.
- Builds a required action on top of a best-effort notice.
- Assumes a missed announcement can be collected again afterwards.
- Assumes every store in this class can emit one.
- Ignores that the emitting copy on a replicated tier varies by store.