A membership sketch sized for 10 million identifiers a day now receives 80 million — what degrades, and what will it never report?
answer
- no ceiling to hit, no error to raise
- the overrun is paid in accuracy
- sizing inputs come from outside
- it is not an inventory
- count additions beside it
basics
~20 sMemory does not move; accuracy does. Wrong 'yes' answers climb well past the planned rate, and the plain structure refuses nothing, raises nothing and reports no fullness — you learn the population only by counting additions yourself.
solid answer
~50 sThe fixed footprint is the contract, so the overrun is paid for in error. The rate you sized for assumed a population of 10 million; at eight times that, the uncertain direction becomes far less trustworthy, and the degradation is gradual and completely silent. Nothing rejects a write, nothing signals that the structure is past its design point, and it cannot tell you how many items it holds, because it keeps none of them. Sizing inputs come from outside: an expected population and an accepted error rate. The repairs are to rotate the entry over a shorter window so the population per entry stays inside the plan, to re-create a larger structure and rebuild it from the authoritative record, or to narrow what is added. And instrument the population separately — a server-side counter of additions alongside the sketch is what tells you the plan has been exceeded.
go deeper
Recall that the footprint is fixed, so more items do not mean more memory. Something else has to give, and that something is how often the uncertain answer is wrong.
Explain the two sizing inputs — expected population and accepted error — and why exceeding the first silently invalidates the second with nothing raising an error.
Show the operational response: measure additions with a separate counter, rotate entries over a window that keeps the population inside the plan, and rebuild from the authoritative record when a re-size is needed.
Treat the sizing assumption as something that must be owned and reviewed, since a forecast made once quietly becomes an accuracy guarantee nobody re-checks as the service grows.
## Why nothing breaks loudly The defining property of the structure — memory chosen at creation, unaffected by what is added — is also why an overrun is invisible. There is no ceiling to hit, so there is no error to raise. Every addition is accepted. Every membership test returns promptly. The only thing that changed is the probability attached to a 'yes', and that probability is not attached to any individual reply. So the symptom is not an outage. It is behaviour drifting: work being skipped that should have been done, duplicates suppressed that were not duplicates, a rate of 'already seen' answers creeping upward for reasons no dashboard attributes to the structure. ## What sizing actually consumes Creating one of these structures takes two inputs, and **both come from outside the structure**: - **The expected population** over the period the entry covers — how many distinct items will be added before it is discarded. - **The accepted error rate** for the uncertain direction. That is why an eightfold overrun is a planning failure rather than a runtime one: the first input was a forecast, and forecasts on a growing service are wrong in one predictable direction. Note also what is *not* an input: nothing about how many items are currently inside, because the structure has no way to tell you. It keeps compressed evidence, not the items, and it is not an inventory. ## What the structure will not tell you - **How many items it holds.** Not an operation it offers. - **Which items it holds.** It keeps none of them. - **That it is past its design point.** The plain form reports no fill level; some implementations do expose an estimate of fullness, and some offer a chained or scaling form that adds capacity as it fills, so check what yours provides rather than assuming either way. - **Which of its answers were wrong.** A wrong 'yes' is indistinguishable from a right one. ## Three repairs 1. **Rotate over a shorter window.** If a day's population is eight times the plan, make each entry cover a shorter period so the population per entry falls back inside it, and query the entries covering the range you care about. The entry is the unit a lifetime attaches to, so items inside cannot be aged out individually — rotation is always by whole entry. 2. **Re-create larger and rebuild.** Allocate a structure sized for the real population and fill it from the authoritative record. There is no upgrade in place and no way to copy across from the old one, because the old one cannot be read back. Plan for the gap while the new one is being filled. 3. **Narrow what goes in.** Often the population exploded because the identifier space got wider than intended — a scope was added to the key, retries are adding distinct values, or something machine-generated is being tracked alongside real traffic. Reducing what is added is the only repair that costs nothing. What is *not* a repair is deleting items to relieve pressure. The plain structure offers no removal; variants that do exist buy it at a cost in error direction, and even where removal is available it is not a way to recover accuracy already spent. ## Instrument the population, not the structure Since the structure will not report its own load, measure the load beside it: keep a plain server-side increment counter of additions per window, and compare it against the population the entry was sized for. That gives you an actionable signal — 'this entry was sized for ten million and has taken eighty' — long before anyone notices behaviour drifting. | you want to know | ask the sketch | ask something else | |---|---|---| | how many items were added | no | a counter incremented on each addition | | how many distinct items exist | no | the authoritative record, or a distinct-count sketch | | whether the error budget still holds | no | the counter, against the planned population | | whether this item was probably added | yes | — | ## What varies between implementations Treat everything above as the model and verify the specifics: whether a fill estimate is exposed, whether a scaling form exists that adds capacity, whether the accuracy setting can be changed after creation, and whether the structure exists server-side in your store at all — where it does not, it lives in the application and the store holds it as opaque bytes, so each addition becomes a read-modify-write round trip. The one thing that does not vary is the shape of the failure: the structure keeps working, at an accuracy nobody is watching.
- How do you pick the rotation window?The shortest window that still answers the question asked of it, sized so the expected population per entry stays inside what the structure was allocated for. Rotation is by whole entry, since a lifetime attaches to the entry rather than to items inside it, and a query over a longer range reads the entries covering that range.
- You re-create the structure at the right size. Where does its content come from?From the authoritative durable record, replayed in. The old structure cannot be read back or copied across, so a re-size is always a rebuild, and during the rebuild the new structure under-reports membership. If no such record exists, the sketch was carrying state that nothing else had — a separate problem worth fixing first.
saying these in an interview costs you the question
- Expects the structure to reject writes once it is full
- Believes deleting old identifiers restores the planned error rate
- Thinks memory climbs with the extra seventy million identifiers
- Reads the sketch itself to learn how many items it holds
- Assumes the planned error rate holds whatever the population becomes
- Waits for an alert the structure has no way to raise