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.

May 16, 2026473 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

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.

jandrewrogers

UUID v4 reliability depends on a high-quality entropy source, which real systems can quietly violate.

CodesInChaos

Frontend generation, VM state duplication, forks, and sandboxed fallbacks all change the risk profile.

sedatk

The uuid library itself documents deterministic browser contexts such as Googlebot as a duplicate risk.

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.

smokel

A collision this early should trigger checks for duplicate processing, replay, reused objects, and misleading logs.

dist-epoch

Bit flips, buffers, index scans, and storage layers can create impossible-looking data artifacts.

mittermayr

The original poster noted that IDs had moved from user devices to server generation, making generation history part of the investigation.

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.

erlkonig

Systems that treat collisions as impossible often have no retry or recovery path when the invariant breaks.

pif

Randomness can make collision difficult, but guaranteed uniqueness has to be built explicitly.

athrowaway3z

Timestamped identifiers such as UUID v7 can be a practical fit when the information leak is acceptable.

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.