HNHN Radar

Saved Ask HN Digest

What should you do after a UUID v4 collision?

A saved Ask HN digest on a reported UUID v4 collision, why engineers suspected entropy and data-path bugs before probability itself, and how to design identifiers so rare events fail safely.

473 points341 repliesEvergreen guide
HN Radar answer

Do not start by assuming the probability model failed. A real UUID v4 collision at about 15,000 records is so unlikely that the thread's strongest advice is to treat it like an incident: preserve evidence, verify every generation path, inspect entropy sources, rule out replay or duplicate processing, and keep a database uniqueness constraint with a retry path. UUIDs are useful, but they are not a substitute for defensive data integrity design.

Original discussionMore Ask digests

Common answers

  1. 01

    Suspect the generation environment before the math

    The most repeated technical explanation is that UUID v4 only behaves as advertised when the random source is high quality and correctly wired. Commenters pointed to client-side generation, deterministic browser or crawler environments, VMs, forks, sandboxes, unsafe fallbacks, and broken RNG initialization as more plausible than an organic collision.

  2. 02

    Rule out ordinary data-path bugs and misleading evidence

    Many commenters argued that the collision should be investigated like any other impossible production event. Duplicate processing, replayed requests, reused objects, misleading logs, migration paths, memory corruption, and client-generated historical IDs can all make a system appear to have produced a clean UUID collision.

  3. 03

    Design identifiers so rare events fail safely

    The durable engineering lesson is not that UUIDs are bad. It is that probabilistic identifiers should still sit behind explicit uniqueness constraints, conflict handling, and an operational response. If the product needs guaranteed uniqueness, the guarantee must be built into the database or ID service rather than assumed from randomness.

Contrarian read

Where the thread disagrees

The useful counterpoint is that replacing UUID v4 is not automatically the answer. Time-based IDs, UUID v7, ULIDs, TSIDs, sequences, and hashes all move tradeoffs around: ordering, guessability, information leakage, coordination, and collision space. The better lesson is to match the identifier to the workload and keep the database invariant explicit.

Practical checklist

What to do before chasing the badge

  1. Preserve the duplicate rows, raw IDs, timestamps, request IDs, library versions, and surrounding logs before cleanup.
  2. Confirm every code path that can create the identifier, including old mobile clients, browser clients, workers, migrations, imports, and tests.
  3. Inspect the randomness source in each environment: Node crypto, browser crypto, VM or fork behavior, sandbox fallbacks, crawlers, and offline clients.
  4. Search for duplicate processing, retries, replayed requests, reused objects, misleading logs, and manual data repair paths.
  5. Keep a database unique constraint on the identifier and add a safe retry path for conflicts.
  6. If clients generate IDs, treat them as provisional or make the server/database the final authority.
  7. Consider UUID v7, ULID, TSID, sequences, or scoped IDs only after writing down ordering, privacy, and coordination tradeoffs.
  8. Add telemetry that records generator environment and collision handling so the next incident starts with evidence.

Source note

Why this page exists

This digest summarizes a public Ask HN thread and links back to the original discussion. It is not a proof about UUID collision probability; use it as an engineering incident checklist and review the original comments for context.