A stream is configured with both a seven-day age bound and a byte ceiling — which one decides when the oldest record is removed?

## The two bounds A store that keeps records for a while needs a rule for when a record stops existing. Platforms in this class typically offer two, and most production streams have both set: - **An age bound** — the maximum age a record may reach before it becomes removable. *Keep seven days.* - **A byte ceiling (a size bound)** — the maximum bytes a named scope may occupy before the oldest records become removable. *Keep five hundred gigabytes.* They are not alternatives, and neither one overrides the other. A background **removal pass** evaluates both, and the oldest records become removable as soon as **either** is reached. That is the whole rule, and it has a name worth using in an interview: **whichever binds first**. Note the direction: a size bound removes the **oldest** records, not arbitrary ones and not the newest. The span of history that survives is therefore always a suffix — the most recent records — and the front of the history is what moves. ## Which one binds is arithmetic, not configuration Given a write rate, each bound implies a span of readable history: - the age bound implies its own number directly (seven days means seven days); - the byte ceiling implies `ceiling ÷ current byte rate`. At 30 GB/day into a scope whose ceiling is 500 GB, the ceiling implies about 16 days, so the 7-day age bound binds first and the ceiling never fires: it is acting purely as a guard on the data volume. Push the rate to 90 GB/day and the ceiling implies about 5.5 days — now the ceiling binds first and the age bound never fires. Nothing has been misconfigured and nothing has failed. The span that survives is a **consequence of throughput**, not a promise made by the configuration. | | age bound | byte ceiling | |---|---|---| | what it measures | how old a record is | bytes held in one stated scope | | under a traffic surge | the span holds, the bytes grow | the bytes hold, the span shrinks | | what it protects | a predictable span of history | the data volume | | how it disappoints you | bytes can grow beyond plan | history shortens with no error | ## The byte ceiling is meaningless without its scope "Five hundred gigabytes" answers nothing until you know **five hundred gigabytes of what**. Platforms state a size bound against different scopes: - **per partition of a stream** — a stream with twenty-four partitions then holds up to twenty-four times the number you typed; - **per stream as a whole** — the number means what it looks like; - **per subscriber backlog** — the bytes counted are the ones a particular subscriber has not taken yet, so the same stream costs more as subscribers are added; - **nowhere** — some platforms express retention only as an age and leave capacity entirely to you. Always say the scope out loud. An operator who quotes a ceiling without its scope cannot size anything. ## The span that survives is the replay budget The span of history still readable right now is **the retention window**, and it is worth naming it as what it actually buys you: the retention window *is* **the replay budget**. It is how far back anything can be re-read — by a reader recovering after a bad deploy, by a new consumer being brought up on history, by an investigation. Whatever the two bounds produce, that is the budget, and it is spent silently. Nobody is notified when it shrinks; there is simply less history there the next time someone looks. ## What varies between platforms - Platforms that split a stream into partitions usually count a size bound per partition and enforce it as the segments of that partition roll closed. - Platforms built around a per-subscriber backlog count bytes, and sometimes an age, against what each subscriber still owes itself. - Some hosted offerings expose an age bound only, and manage the bytes themselves. - Where a size bound exists at all, oldest-first removal is near-universal; where it does not, age is the only lever you have. Saying *which* model you are describing is not hedging — it is the content. A candidate who describes only the shape they have personally run is the one an interviewer catches. ## What interviewers listen for - The phrase **whichever binds first**, not "the stricter one" and not "one overrides the other". - That the byte ceiling needs a **scope** before it means anything. - That the age bound is a **ceiling on age**, not a guarantee of survival. - That the readable span is a derived quantity you should be watching, not a setting you can read off a configuration page.