A hold that suspends removal is placed on a stream whose byte ceiling still binds, so what collides and who has to decide?

## What a hold actually is A **hold** is a rule that suspends removal for some set of records regardless of the bounds configured on the stream. Some stores implement it as a first-class feature, some as a bound temporarily raised beyond the period in question, and some estates implement it as a written instruction and a disabled automation. The mechanism varies; the effect does not. For the duration of the hold, a defined span of history is not a candidate for removal. That single sentence is where the operating collision comes from. ## The collision A store under a **byte ceiling** is normally self-correcting: bytes accumulate, the ceiling is approached, the removal pass drops the oldest closed segments, headroom returns. It is a control loop, and a hold cuts the feedback path while the input continues. Writes arrive at the same rate; the only mechanism that ever released space has been switched off for the held span. So two rules that both looked reasonable in isolation now point in opposite directions: - The hold says: **none of this may be removed**, on a clock nobody in the engineering organisation controls. - The byte ceiling says: **this much is all there is**, on a clock set by how fast writers write. Something has to give, and the person on call is usually the one who discovers this — often weeks after the hold was agreed in a meeting they were not in. ## The responses, in the order they are normally reached for 1. **Narrow the hold's scope.** Holds are frequently written against an estate or an application when the obligation concerns one stream and one span of time. Scoping it to what is actually in question is the cheapest move and the one most often available, because it costs nothing technically — but it must be agreed by whoever placed the hold. 2. **Buy capacity.** Give the store more room so the ceiling stops binding before the hold ends. Straightforward, has a bill attached, and needs an end date to be sized against. 3. **Move the held records where the ceiling does not apply.** Copy the held span out to separate storage under the same obligation, then let the stream's normal bounds resume for everything else. This converts a live capacity problem into an archive with an owner, and it introduces a second place the same bytes now live. 4. **Reduce what is arriving.** Stop or slow the writers producing into the held span. Rarely acceptable, but it is a real lever and naming it shows you know the loop has two sides. What is *not* on the list is the fastest move available on any other day: cutting the bound so the oldest history goes. On a stream under a hold, that action is not a trade-off, it is the violation itself. ## Who decides This is the half of the question that separates seniors. Every item on that list either spends money, changes the scope of a legal instrument or stops a business process. None of them is an on-call action, and an operator who quietly picks one has made a legal decision without the authority to make it. The engineering job is to convert the collision into a decision someone else can take: here is the date the ceiling binds, here is what each option costs, here is what I need decided and by when. That means three numbers have to exist before the hold is accepted, not after: - **The rate.** How fast the held span, plus ongoing writes, is consuming headroom. - **The date.** When the ceiling binds at that rate. This is the deadline the decision is really on. - **The end condition.** What event lifts the hold, and who declares it. ## Holds that never end The recurring estate-level failure is a hold with no recorded owner and no end condition. It was placed for a matter that concluded, nobody told the platform team, and years later a stream is carrying history that no rule requires and no one will authorise removing, because the person who could say so has left. Every hold should be recorded with its scope, its owner, its reason and the condition that lifts it, and the register should be reviewed on a schedule — otherwise the safe default of "leave it on" accumulates until it is a capacity line item nobody can explain. ## What varies between platforms Whether the ceiling is even yours to raise depends on the shape you are running. On a store you operate, adding capacity is a purchase and a rebalance. Where the platform applies bounds per subscriber rather than per stream, a hold has to be expressed against each of those scopes and one can bind long before another. Where the cluster is rented, there may be a ceiling you cannot raise at any price, which removes option two from the list entirely and makes scope and relocation the only levers. Say which shape you are assuming before you commit to a plan. ## What an interviewer is listening for Two things. First, that you see the collision at all — that a hold is not free, because it disables the mechanism the ceiling depends on. Second, that your instinct is to escalate with numbers rather than to resolve it yourself. A candidate who says "I would raise the bound back and cut the oldest history" has just described the breach the hold existed to prevent.