UUID & ID Generation

The ID Generation Problem

In distributed systems, we need to generate unique identifiers for:

• Database records: Primary keys
• Request IDs: Tracking requests across services
• File names: Avoiding collisions
• Session IDs: User sessions
• Order IDs: E-commerce orders

The Challenge: How do we generate unique IDs across multiple nodes without coordination? How do we ensure no collisions? How do we make IDs sortable and efficient?

Sequential IDs: The Problem

Sequential IDs (like database auto-increment) require coordination:

Problems:

• Single point of failure: Database must be available
• Bottleneck: All nodes compete for ID generation
• Doesn’t scale: Can’t generate IDs in parallel
• Reveals information: Sequential IDs reveal order count, user count

Not suitable for distributed systems!

UUID (Universally Unique Identifier)

UUID is a 128-bit identifier that’s globally unique without coordination.

UUID v4 (Random)

UUID v4 uses 122 random bits (4 bits for version/variant).

Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

• 4 = version 4
• y = variant (8, 9, A, or B)

Characteristics:

• Globally unique: Collision probability extremely low
• No coordination: Each node generates independently
• Not sortable: Random, no time ordering
• 128 bits: 16 bytes

Use Cases:

• Distributed systems requiring uniqueness
• When sortability not needed
• When you don’t want to reveal information

UUID v7 (Time-Ordered)

UUID v7 uses timestamp + random bits (time-ordered).

Format: xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx

• 7 = version 7
• First 48 bits = Unix timestamp (milliseconds)
• Remaining bits = random

Characteristics:

• Time-ordered: Sortable by generation time
• Globally unique: Still very low collision probability
• Better for indexing: Time-ordered improves database index performance
• 128 bits: 16 bytes

Use Cases:

• When sortability matters (database primary keys)
• When you want time ordering
• Better than v4 for database indexing

Snowflake Algorithm

Snowflake is Twitter’s ID generation algorithm. Generates 64-bit time-ordered IDs.

Structure

64-bit ID:
├─ 41 bits: Timestamp (milliseconds since epoch)
├─ 10 bits: Machine ID (0-1023 machines)
└─ 12 bits: Sequence number (0-4095 per millisecond)

How It Works:

1. Timestamp: Milliseconds since custom epoch (e.g., 2020-01-01)
2. Machine ID: Unique ID for each machine (assigned at startup)
3. Sequence: Increments for IDs generated in same millisecond

Performance:

• ~4 million IDs per second per machine
• Time-ordered (sortable)
• Compact (64 bits = 8 bytes)

Requirements:

• Clock synchronization: Machines must have synchronized clocks
• Machine ID assignment: Need to assign unique machine IDs
• Sequence management: Handle sequence overflow

ULID (Universally Unique Lexicographically Sortable Identifier)

ULID combines timestamp and randomness in a lexicographically sortable format.

Structure

128-bit ULID:
├─ 48 bits: Timestamp (milliseconds since 1970-01-01)
└─ 80 bits: Random

Format: 01ARZ3NDEKTSV4RRFFQ69G5FAV (Base32 encoded, 26 characters)

Characteristics:

• Lexicographically sortable: String comparison matches time order
• Time-ordered: First 48 bits are timestamp
• URL-safe: Base32 encoding (no special characters)
• 128 bits: Same size as UUID
• Better than UUID v4: Time-ordered improves database performance

Use Cases:

• Database primary keys (better indexing than UUID v4)
• When you need sortable string IDs
• When UUID v4 randomness causes index fragmentation

ID Generation Implementation

Comparison

Feature	UUID v4	UUID v7	Snowflake	ULID
Size	128 bits	128 bits	64 bits	128 bits
Sortable	No	Yes	Yes	Yes
Coordination	None	None	Machine ID needed	None
Performance	Fast	Fast	Very fast	Fast
Collision Risk	Very low	Very low	Very low	Very low
Database Indexing	Poor (random)	Good (time-ordered)	Excellent	Excellent

Use Case Selection

Use UUID v4 when:

• Need globally unique IDs
• Sortability not important
• Don’t want to reveal information
• Simple implementation needed

Use UUID v7 when:

• Need time-ordered IDs
• Better database indexing
• Want UUID format compatibility
• Can use newer UUID version

Use Snowflake when:

• Need compact IDs (64 bits)
• Very high throughput needed
• Can coordinate machine IDs
• Time-ordered important

Use ULID when:

• Need lexicographically sortable string IDs
• Better database indexing than UUID v4
• URL-safe format needed
• Time-ordered important

Key Takeaways

No Coordination

UUID, ULID generate unique IDs without central coordination. Snowflake needs machine ID assignment but no runtime coordination.

Time-Ordered

UUID v7, Snowflake, ULID are time-ordered. Improves database indexing performance compared to random UUID v4.

Collision Probability

All algorithms have extremely low collision probability. UUID v4: ~5×10^-37 for single collision. Practical systems don’t worry about collisions.

Choose Wisely

Consider size, sortability, coordination needs, and database indexing when choosing ID generation strategy.

---

Next Steps

• Learn Database Indexing - ID choice affects indexing performance
• Master Distributed Systems - ID generation in distributed context
• Understand Event Sourcing - IDs used in event stores