An approximate membership sketch gates a one-time signup bonus: a 'yes' means already paid, so payment is skipped. What breaks, and what repairs it?

## Which branch the uncertainty lands on An approximate membership sketch is a fixed-memory structure that answers *have we seen this before*, and on the structures normally chosen for membership the two answers are not equally trustworthy: a 'no' is certain, while a 'yes' carries a bounded chance of being wrong. The chance is small and it is never zero, and it is not reported per answer — nothing in the reply distinguishes a wrong 'yes' from a right one. The design in the question attaches the consequential branch to the untrustworthy answer. Its failure looks like this: - A genuinely new account is answered 'yes'. - The bonus is skipped. - No exception is raised, no counter increments, nothing is queued for retry — the system is doing exactly what it was told. - The user was expecting money, did not get it, and there is no evidence anywhere that it was withheld. That combination — irreversible, user-visible, silent — is precisely the case in which an approximate answer must not be the last word. ## Check the direction, do not assume it Before wiring any branch to a sketch, confirm which direction the specific structure can be wrong in. It is a property of the structure you were handed, not of the class. Structures that estimate how often something has been seen typically over-count. Variants that permit removing an item generally trade one-sided error for error in both directions, which would make even the 'no' branch unsafe here. The whole safety argument collapses if the direction is assumed rather than read. ## The rule, in four steps 1. **Name the action behind each answer.** Not 'the check', but what actually happens: money is sent, money is withheld, an email goes out, a job is skipped. 2. **Establish which direction the structure guarantees**, and make sure that is the one the consequential action hangs on. 3. **If the uncertain direction drives something irreversible or user-visible, put a cheap exact confirmation behind it** — read the authoritative record before taking the irreversible branch — or do not use a sketch at that point at all. 4. **Decide what happens when the sketch is gone.** On a volatile tier this is not hypothetical. Applied here, the repaired flow is: a 'no' pays immediately, because a 'no' is certain; a 'yes' triggers a read of the authoritative payment record, which decides. The sketch has not become useless — it still answers most of the traffic without touching the record of truth — but the answer that can be wrong no longer decides anything on its own. ## Why a smaller error rate is not the fix Allocating more memory lowers the frequency of a wrong 'yes'; it does not change its class. At a million signups, a rate small enough to sound negligible still denies a measurable number of real people their bonus every day, silently, with no path to detection because nothing in the system knows it happened. Changing a failure from frequent-and-silent to rare-and-silent is not a control. Only the confirmation step turns it into a failure that cannot occur. ## What each answer is safe to drive | answer | what it means | safe to act on alone | why | |---|---|---|---| | 'no' | definitely never added | yes | the certain direction on these structures | | 'yes' | probably added | only if the consequence is cheap and reversible | the direction that can be wrong | | no sketch (entry lost) | nothing is known | no | every identifier reads as never seen | ## The volatile-tier half of the problem A sketch on this tier is an ordinary entry. It can be lost to a restart, to a failover, or to pressure at the memory ceiling, and what a store keeps across a restart varies widely across this class — some keep nothing at all, others write a point-in-time copy or a log of writes, and the guarantee is a configuration decision rather than a property of the class. When the entry is gone, every identifier reads as 'never seen'. The failure mode inverts: instead of silently denying real users, the system happily pays everyone a second time. So the design has two distinct risks pointing in opposite directions, and the authoritative record is what bounds both. Once that record is being consulted before the irreversible branch, the sketch is an optimisation whose loss costs throughput rather than money. One more shape consequence: a lifetime attaches to the entry, not to anything inside it, so 'seen' accumulates for as long as the entry lives and individual identifiers cannot be aged out. If your question is really 'seen in the last hour', that has to be expressed as a rotated entry per window, not as an expiry on a member.