Live Ticks Expire

"A live price is a guest, not a resident. It gets fifteen minutes, then the durable close takes its chair back."

Live is an overlay, not a replacement

When streaming is on, a live tick gives you the most current price. But Keep never lets that live value become the truth — it's a temporary overlay painted on top of the durable close, and it has an expiry. After LIVE_TTL_SECONDS — fifteen minutes — the live tick expires, and ownership of "the current value" returns to the stored, completed close. The durable close is the resident; the live tick is a guest with a timer.

Why the expiry matters

Imagine no expiry. You open Keep, streaming runs for a while, then your laptop sleeps, or the network drops, or you wander off. The last live tick is now frozen on screen — a price from an hour ago, or yesterday, sitting there looking exactly as authoritative as a fresh one. That frozen tick is the most dangerous kind of stale data: it looks live but isn't. The TTL kills that failure mode. Once fifteen minutes pass without a new tick, Keep stops trusting the old one and falls back to the durable close, which at least honestly carries its own date. A known close beats a lying tick.

Ephemeral data must carry its own expiry, or it becomes a lie by default. A value that's only valid for a moment will, without a TTL, keep being displayed as valid long after the moment passes. Time-bounding volatile data isn't an optimization — it's the difference between 'currently live' and 'frozen from an hour ago, pretending.'

The layering, made explicit

Keep's current value for any instrument is a small stack: the durable completed close at the bottom (always present, always dated), with a live tick painted on top only while it's fresh. Reads resolve top-down but respect the TTL — a live tick within its window wins; an expired one is ignored as if it were never there. This is what lets "pause" be safe (next lesson): pausing just stops new ticks, and the existing overlay ages out on its own, leaving the honest durable close in charge.

The resting state is always the durable close. Everything about live pricing is designed so that when the excitement stops — you pause, you close the laptop, the TTL lapses — the surface settles back to the calm, dated, stored close rather than a stuck live number. Live is the exception you opt into; the completed close is home base.

Code

A live tick wins only within its TTL (illustrative)·typescript

const LIVE_TTL_SECONDS = 15 * 60;

function currentValue(durableClose: Close, liveTick: Tick | null): Value {
  if (liveTick && ageSeconds(liveTick) < LIVE_TTL_SECONDS) {
    return { value: liveTick.value, basis: "live" };   // fresh overlay wins
  }
  // No tick, or an expired one: fall back to the dated durable close.
  // An expired tick is treated as if it never existed.
  return { value: durableClose.value, basis: "close", asOf: durableClose.date };
}

// A stale tick can never masquerade as the current price:
// past the TTL, the honest close quietly takes ownership back.

Exercise

Find a place in a UI where a 'live' or 'real-time' value is shown. Ask: what happens if the updates simply stop (sleep, disconnect, tab backgrounded)? Does the last value freeze and keep looking authoritative? Design a TTL: after how long should that value stop being trusted, and what does it fall back to? Describe the difference between 'currently 42' and 'was 42 an hour ago, frozen.'

Hint

The dangerous case is a value that looks live but isn't updating anymore — a frozen tick is worse than a labelled stale value because nothing signals that it stopped. A TTL plus an honest fallback ('reverting to last close as of...') turns a silent freeze into a visible, correct downgrade.

Live is an overlay, not a replacement

Why the expiry matters

The layering, made explicit

Code

External links

Exercise

Progress

Comments 0