GenerateRandomSearch

Why coincidences are likelier than they look

Why do improbable-looking coincidences keep happening, and when should that actually worry you?

Two people in a room of twenty-three sharing a birthday feels like it should be rare, and it is more likely than not. The reason is not that the odds are strange but that almost everybody counts the wrong thing, and the same miscount is behind a whole class of engineering mistakes — random identifiers colliding far sooner than their length suggests, short codes running out long before anybody expected. It is one piece of arithmetic with two very different audiences.

You are counting yourself, not the pairs

Asked whether somebody in a room of twenty-three shares your birthday, most people picture twenty-two comparisons and correctly conclude it is unlikely — about six per cent. That is a perfectly good piece of reasoning and it is the right answer to a different question from the one that was asked, which is the whole of why the real answer feels wrong when you first hear it.

The actual question is whether any two people share, and twenty-three people make 253 pairs. Every pair is an opportunity, and pairs grow quadratically while people grow one at a time. That gap between 22 and 253 is the whole of the surprise, and once you see it the answer stops being counter-intuitive.

The arithmetic runs the other way round from how the question is asked: compute the chance that everybody is different — the first person can have any birthday, the second must avoid one, the third must avoid two — and subtract from one. Computing the collision case directly would need inclusion-exclusion over every subset, which is both slower and much easier to get wrong. It is a general lesson about probability worth carrying: when a question asks for the chance of at least one of something, the tractable route is almost always through the chance of none of it.

The square root is the number to remember

Collisions become likely near the square root of the number of possibilities, not near half of it. That single fact is what makes the birthday problem useful outside a party: a million possible six-digit codes start colliding around a thousand issued, not around half a million.

This is why short random identifiers fail so much earlier than intuition allows. A four-character code from an alphabet of thirty-two has about a million possibilities and is in trouble after a few hundred. Doubling the length does far more than doubling the safe volume, because the space grows exponentially and the threshold grows as its square root.

The engineering version of the rule: work out your expected volume, square it, and compare that with the size of your space. If those numbers are close, you will get duplicates — and if duplicates would be expensive, the answer is not a bigger space but checking on insert.

Where the same arithmetic gives the opposite answer

The birthday problem makes coincidences look common. A lottery makes the opposite point with the same kind of counting, and the two are worth holding together: matching six numbers from forty-nine is one in 13,983,816, and no amount of pairs or people changes that, because you are matching against one fixed draw rather than against everybody else.

The distinction is whether the comparison is one-to-many or many-to-many. Sharing your birthday is one-to-many and stays unlikely. Any two people sharing is many-to-many and becomes likely fast. Reading across between the two is where most bad intuition about probability comes from.

It is also why a coincidence is weak evidence of anything. Given enough pairs of things, some of them will match, and noticing afterwards that a particular pair matched is not the same as predicting it beforehand. The number of comparisons nobody made is invisible, and it is usually enormous — which is why a striking coincidence is better treated as a fact about how many opportunities there were than as a fact about the thing that happened.

When to actually worry

For a party, never. The birthday problem is a good trick and nothing more, and the fact that it reliably surprises people is the entire point of telling them. Nobody has ever been harmed by two guests sharing a birthday, and the coincidence carries no meaning worth reading into — it is simply what a room of that size produces most of the time.

For anything issuing random identifiers, the threshold to watch is not 50% but 1%. By the time collisions are more likely than not you have had them for a long while, and the failure usually surfaces as something unrelated — a duplicate key, an overwritten record, a support ticket nobody can reproduce. The gap between the first collision and anybody noticing is where the real cost sits, because by then the duplicate has usually been copied somewhere else.

And if a duplicate would be genuinely costly, do not rely on probability at all. Check for a collision when you insert. The arithmetic here tells you how often you should expect that check to fire, which is a much better use of it than choosing a length and hoping.

The bottom line

Count the pairs, not the people, and remember that collisions arrive near the square root of the space. For a party that makes a good trick; for anything issuing random codes it means the safe volume is far smaller than the space suggests, and the 1% threshold is the one to design against.

Other guides