When does it matter whether a deadline was sent as a duration the store counts down or as an instant the caller computed?
answer
- one clock, or two?
- duration normalises, instant imports skew
- a lagging refresher can move it back
- state which node answered the read
- window much larger than worst-case skew
basics
~20 sIt matters as soon as clocks disagree. A duration is counted down on the store's clock; an instant the caller computed is only as good as that caller's clock, so skew makes the entry lapse early or late.
solid answer
~50 sThe two forms look interchangeable and are not. When the caller sends a **duration**, the store converts it against its own clock, so one clock is involved and the worst error is the delay between the caller deciding and the store receiving. When the caller sends an **instant** it computed itself, two clocks are involved: the writer's produced it, the store's compares against it. A writer running minutes fast produces entries that lapse early; one running slow produces entries that outlive their window, and across a fleet with mixed offsets the same logical lifetime differs per writer with nothing reporting it. Refreshing makes it worse in the instant form, because a refresher whose clock lags the writer's can move a deadline **backwards**. Prefer durations; where an instant is unavoidable, keep it in the value, compare it against a single clock, and keep the window far larger than worst-case skew.
go deeper
Remember that asking for "thirty seconds" and asking for "gone at half past" are different requests. The first uses the store's clock; the second uses yours, and yours can be wrong.
Explain the mechanics: a duration involves one clock and bounded network delay, a computed instant involves two clocks and unbounded disagreement between them.
Show the production case: entries lapsing early only for writes from certain hosts, a refresh that pulled a deadline backwards, and the switch to durations that made the class of bug disappear.
Decide the posture. State whether the tier's deadlines are durations by policy, what the tier promises when clocks disagree, and how much skew a design may assume before it must stop relying on a deadline at all.
## Two forms of the same instruction Asking a store to stop serving an entry after some time can be expressed two ways, and the difference is not cosmetic. | | A duration the store counts down | An instant the caller computed | |---|---|---| | Whose clock decides | The store's, only | The caller's produces it, the store's compares against it | | Effect of caller clock skew | None | The entry lapses early or late by exactly the offset | | Effect of network delay | The countdown starts slightly late | None; the instant is already absolute | | What a refresh does | Resets to a full window | Moves the deadline to wherever the refresher's clock says | | Behaviour across hosts with different offsets | Identical | Differs per writer, silently | A duration is self-normalising: whatever the caller believes the time is, it asked for "this long", and the store answers in its own time base. An instant imports the caller's clock into the store's decision. ## Where the instant form bites - **A fleet with mixed offsets.** Hosts drift apart; a minority with a several-minute offset produce entries with visibly different lives, and the effect shows up as a scattering of early or late disappearances rather than as a clock alarm. - **A clock step.** A host whose clock is corrected forward or backward by an adjustment produces instants on either side of the jump. Nothing rejects them; a deadline can be computed in the past and the entry effectively never serves at all. - **A refresh that moves the deadline backwards.** Under an idle deadline expressed as instants, a caller whose clock lags the original writer's computes a deadline earlier than the one already attached. Where the operation simply overwrites the deadline, the entry now goes sooner than before it was refreshed. - **Suspended machines.** A host resumed after a pause may compute instants from a clock that has not caught up yet. ## Whose clock, and which node answered the read When the tier is more than one machine, "which clock" gains a second half: which node decided, and which node answered the read. Designs differ, and this is worth saying explicitly rather than assuming. - On some stores the node that owns the entry decides that the deadline has passed and propagates the removal, so every copy agrees regardless of its own clock. - On others each copy counts down on its own, and a read served by a different copy can be answered from a copy whose clock has not yet reached the deadline. So an item about early or late disappearance is not answerable until three things are stated: whether the deadline was a duration or an instant, which clocks are in play, and which node answered the read. Where a design cannot state all three, the safe posture is to keep windows generous relative to plausible skew, so that being seconds wrong never changes an outcome anyone cares about. ## Repairs, in order of preference 1. **Send durations.** The store applies its own clock, and the caller's clock stops being part of the correctness argument. This alone removes most of the class. 2. **If an absolute moment genuinely matters, carry it in the value** and evaluate it where you can guarantee one clock — comparing two values produced by the same source rather than mixing a writer's timestamp with a reader's notion of now. 3. **Size the window well above worst-case skew.** A window of seconds on a fleet that drifts by seconds is a design that fails intermittently; the same design with a window of minutes does not. 4. **Monitor the offset.** Clock offset across the fleet is a signal worth watching in its own right, because nothing in the tier will report a deadline that was wrong by construction. ## The answer that lands Start by refusing the ambiguity: ask, or state, whether the deadline is a duration or an instant, because the whole answer turns on it. Then give the mechanism — one clock against two — and one consequence you have actually seen, such as entries lapsing early only for writes that landed on a subset of hosts. Close with the preference for durations and the reason it is a preference rather than a rule: some designs genuinely need the entry to stop at a real moment in the world, and those pay for it with a clock argument they must then make explicitly.
- Under an idle deadline expressed as computed instants, how can a refresh shorten an entry's life?The refreshing caller computes the new deadline on its own clock. If that clock lags the original writer's, the instant it produces is earlier than the deadline already attached, and an operation that simply overwrites the deadline pulls it backwards — so the refresh, intended to extend the entry, brings its end closer.
- Does sending a duration make the deadline exactly right?No, it makes it depend on one clock instead of two. The countdown starts when the store receives the write, so the network delay between the caller deciding and the store applying it shifts the deadline slightly later. That error is bounded by latency rather than by clock drift, which is usually orders of magnitude smaller.
- A read on a copy of the tier returns an entry the writer believes is past its deadline. What do you need to know before calling it a bug?Whether the deadline was a duration or an instant, whether the copy counts down independently or is told to remove the entry by the node that owns it, and which node answered the read. Stores differ on all three, and the same observation is correct behaviour on one design and a defect on another.
saying these in an interview costs you the question
- Treats a duration and a computed instant as interchangeable
- Assumes every host's clock agrees with the store's
- Sizes a window of seconds on a fleet that drifts
- Says a refresh can only push a deadline later
- Assumes every copy of the tier expires an entry identically