Hold-Back Window
also called Publication Hold-Back, Completeness Hold
The deliberate delay between a period ending and its data being published, sized from the measured arrival curve so that consumers read a number that will not move rather than an early number that will.
An event pipeline partitions by event date. Measured over a quarter, 96% of a day's events have landed one hour after midnight, 99.3% after six hours, and 99.9% only after three days, because mobile clients retry for days on bad networks.
Yesterday's figure read at 08:00 is about 4% low; read at lunchtime it is higher. Nothing errors, and the business learns that the warehouse is unreliable - the most expensive lesson a data platform can teach.
A hold-back window converts that invisible error into a stated delay: the partition publishes only once measured completeness passes a threshold. Threshold and delay come from the arrival curve rather than a policy document, and the window is what people argue about, because it trades freshness for stability directly.
Why it matters
Completeness is the quality dimension most often asserted and least often measured. A team that has not plotted its arrival curve cannot say whether late data is a 4% problem resolved in hours or a 20% problem resolved in days, so it cannot choose between publishing early and holding back. The curve is a property of the clients rather than the pipeline, which is why a mobile release changes it and nothing notices.
The second reason is the shape of the gap. The late 0.7% is not a random sample: it concentrates in the client versions, geographies and networks whose events retry, so the early read is low in a way that moves the country mix and every per-platform metric. A completeness percentage states the size of the gap and says nothing about its shape.
Implementation patterns
- Derive the window from a measured curve: share landed at one hour, six hours, one day and three days, by source.
- Publish two objects over one definition. A fast view with a completeness column per row group and a restatement rule, and a stable view exposing only partitions past the threshold. Consumers choose and the choice is recorded.
- Carry completeness as data, not as a dashboard caveat, so a downstream model can filter on it.
- Alert on the curve shifting, not only on the threshold being missed - a moved curve invalidates every threshold set against the old one.
- Make the override explicit - an action that stamps the partition provisional, not a manual rerun - and chain the window into downstream SLOs.
Industry example
Stream processing engines have carried this idea in production for years: a watermark advances when the engine believes it has seen events up to a point in time, and configured lateness decides what happens to later arrivals. A hold-back window is the same bet in governance form, applied to batch publication and stated to humans: the engine's watermark is an internal progress marker, and a hold-back window is a published promise about when a number stops moving. Teams running both find two answers to one question, usually at the month-end where the mart and the stream disagreed.
Failure scenarios
- The never-published partition. An upstream delay keeps completeness under the threshold and the blank dashboard is read as an outage, so the team is paged for behaving correctly.
- The manual override that becomes routine, after which the control is advisory and nobody knows which historical figures were provisional.
- Shape blindness: the total passes 99% while a per-country metric is 15% short, often because the threshold was set against a curve that has moved.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Hold back to a threshold | numbers that do not move | hours of freshness daily - blank reports during incidents |
| Publish early with completeness | the number exists when it is needed | consumers must restate - some ignore the column |
| Publish early silently | simplest pipeline | the business stops trusting the warehouse |
When not to use it
If the arrival curve is already steep - 99.9% within an hour, typical of server-side events with no client retry path - a hold-back window is machinery for a problem you do not have, and a plain freshness check is enough. Measure before building.
It is also wrong where the consumer can restate cheaply. A dashboard a human reads is better served by an early number labelled 96% complete than by six hours of silence; the rule flips the moment that dashboard feeds an automated action, a payout or a filing, where publishing once and late is the only safe order.
Interview question
Q: Your daily revenue figure changes between morning and afternoon and finance has noticed. You have 90 days of arrival data. How do you decide what to publish and when?
What a strong answer covers: plot the arrival curve first · two views over one definition · completeness as a column · the bias in the late tail and not just its size · the month-end override path · the alert on the curve moving.
Quick check
Quiz: What does a completeness threshold not tell you? - The shape of the gap: the late tail concentrates in particular clients and geographies, so sliced metrics stay wrong while the total passes.
Flashcard: When hold back rather than publish early with a completeness column? - When the consumer cannot restate: payouts, filings, anything sent to a customer.