Understanding UUIDs
A UUID (Universally Unique Identifier) is a 128-bit number standardised by RFC 4122. Unlike incrementing integers (1, 2, 3…), UUIDs are unique without coordinating with a central authority. They're essential in distributed systems where you can't rely on a single database to hand out sequential IDs.
UUID v4: Pure Randomness
UUID v4 is the most commonly used variant. It consists of 122 bits of random data and 6 bits of version/variant information. Because it's random, you can generate UUIDs independently on thousands of servers without worrying about collisions.
Best for: Database primary keys, API request tracking, session identifiers, temporary tokens, distributed system IDs.
UUID v7: Timestamp + Random
UUID v7 (introduced in 2023) combines a 48-bit timestamp with 80 bits of randomness. This makes UUIDs sortable by creation time — useful for databases where you want insertion-order locality without relying on auto-increment sequences.
Best for: Microservices with natural timeline tracking, event sourcing, time-series databases, leader election, any distributed system where order matters.
Nano ID: URL-Safe Alternative
Nano ID is a smaller alternative (21 characters vs 36 for UUID). It's URL-safe and uses a more efficient alphabet. While less standardised than UUID, it's gaining popularity in modern applications because it's shorter and doesn't require parsing.
Best for: URL slugs, short identifiers, applications where string length matters.
Practical Uses
Database Primary Keys
Instead of auto-increment integers, many modern databases use UUIDs. This lets you generate IDs on the client before inserting, useful for offline-first applications. Store as CHAR(36) or BINARY(16).
API Request IDs
Include a UUID in the X-Request-ID header of every API call. This helps with logging, debugging, and distributed tracing. Client generates it, server logs it, both use the same identifier to correlate requests across services.
Session & Token IDs
Web sessions, OAuth tokens, and temporary credentials often use UUIDs. They're random enough to prevent guessing and distributed enough for microservices.
Event & Log Correlation
In microservices, the same user action triggers events across multiple services. Attach a UUID to each "flow" and log it everywhere. Later, you can query all services by that UUID to see the complete transaction path.
UUID vs Other Identifiers
| Type | Format | Sortable | Distributed | Best For |
|---|---|---|---|---|
| Auto-increment (1, 2, 3) | 32-bit or 64-bit integer | ✓ Yes | ✗ No | Single database, simple case |
| UUID v4 | 8-4-4-4-12 hex (36 chars) | ✗ No | ✓ Yes | Distributed systems, multi-server |
| UUID v7 | 8-4-4-4-12 hex (36 chars) | ✓ Yes | ✓ Yes | Modern distributed systems |
| Nano ID | URL-safe alphanum (21 chars) | ✗ No | ✓ Yes | URLs, short identifiers |
| ULID | Crockford Base32 (26 chars) | ✓ Yes | ✓ Yes | Sorted IDs with timestamps |
Collision Probability
UUID v4 has 122 bits of entropy. The birthday paradox says you need roughly √(2^122) ≈ 2.71 × 10^18 IDs before a 50% collision chance. If you generate 1 billion per second, that's 86 million years. For practical purposes, collision is not a concern.
That said, don't use UUID as a cryptographic secret. It's not random-enough for security tokens. For those, use crypto.getRandomValues() or a server-side secret generator.