Balls and Bins and the Birthday Problem
Throwing random items into random buckets sounds simple, but collisions happen far sooner than intuition expects — the same math explains shared birthdays, hash collisions, and how few random trades it takes before two land in the same microsecond bucket.
Prerequisites: Permutations and Combinations, Kolmogorov's Axioms of Probability
A trading system assigns each incoming order a random 6-digit tag for logging. With a million possible tags, it feels safe to assume no two orders in a busy hour will ever collide. That intuition is wrong by a wide margin — the same wrongness that makes "what are the odds two people in this room share a birthday" surprise almost everyone. Balls-and-bins problems ask how many random placements it takes before some bucket gets more than one item, and the answer is always far smaller than "half the number of buckets."
An analogy: filling a hotel at random
Imagine a hotel with 365 rooms, and guests are assigned rooms uniformly at random, one at a time. You might guess you'd need over 180 guests (half the rooms) before two land in the same room. In reality it takes only about 23. Every new guest has to avoid a room already taken by any prior guest, and the number of "already taken" rooms grows with each arrival — the risk compounds combinatorially, not linearly, reaching 50% far faster than intuition expects.
The math, one piece at a time
Suppose there are bins and you throw balls, each landing independently and uniformly in one of the bins. Let be the probability that every ball lands in its own empty bin — no two share a bin. The first ball always finds an empty bin. The second must avoid the first ball's bin: probability . The third must avoid two taken bins: probability . Multiplying these survival probabilities together:
In words: each new ball's chance of dodging every bin already used shrinks a little, and the overall no-collision probability is the product of all those shrinking odds. Using the approximation for small , this product is approximately , so the collision probability is roughly
Plain English: collisions become likely once grows to around , not around — the square root of the bin count, which is a dramatically smaller number than most people's gut estimate.
Worked example 1: the birthday problem itself
With days and people, . So — just over 50%, matching the well-known result that 23 people gives roughly even odds of a shared birthday. Note that , close to 23, confirming the square-root rule of thumb.
Worked example 2: order-tag collisions
Back to the logging system: possible tags. How many orders before there's a 50% chance two share a tag? Setting gives , so . Just over a thousand orders — likely inside a single busy minute — already gives a coin-flip chance of a duplicate, even though the tag space has a million values.
What this means in practice
Balls-and-bins reasoning shows up anywhere random IDs, hash keys, timestamps, or bucket assignments are used at scale: hash table collision rates, the odds two independently-generated trade IDs coincide, or how many random samples you can draw before two land in the same discretized price bucket in a backtest. The rule of thumb — collisions become likely once the count of items reaches roughly the square root of the number of bins — is worth memorizing precisely because it's so much smaller than intuition suggests.
When items are thrown uniformly at random into bins, the probability of at least one collision crosses 50% once reaches roughly , not roughly — collision probability grows like , not , because each new item must avoid every previously placed one.
The classic mistake is reasoning "there are possible values, so I'd need close to draws before worrying about a duplicate." That reasoning implicitly asks about one specific value being hit twice, which is genuinely rare until approaches . The birthday problem asks a different question — whether any two of the items collide with each other, which involves possible pairs, not one target. Confusing these two questions is why the square-root threshold feels wrong the first time you see it.
Related concepts
Practice in interviews
Further reading
- Feller, An Introduction to Probability Theory and Its Applications, vol. 1, ch. 2
- Mitzenmacher & Upfal, Probability and Computing, ch. 5