Domain-Specific UUIDs: When Standard Formats Aren't Enough

UUIDs have earned their place as the go-to for global uniqueness — compact, consistent, and collision-resistant.

But some domains demand more.

From games and mobile apps to telecom equipment and IoT firmware, traditional UUIDs can feel too bulky, too opaque, or just plain inefficient.

Let’s explore where standard formats fall short — and how domain-specific UUIDs evolve to fit unique needs.

🧱 What’s in a UUID?

A UUID (Universally Unique Identifier) is typically 128 bits, displayed as:

It provides:

• High entropy (122+ bits of randomness or structure)
• Consistent format across systems
• Parsability and tooling support

But it doesn’t provide:

• Semantic meaning
• Space optimization
• Local ordering or compression

🎮 Case Study 1: Gaming — Speed & Size Matter

Games deal with millions of in-memory objects: bullets, players, loot, temporary effects. Using full 128-bit UUIDs for every object? Overkill.

Problem:

• Memory-constrained environments
• High-frequency ID generation
• Latency-critical interactions

Solution:

Custom 64-bit IDs with:

• 32 bits: timestamp or tick number
• 16 bits: server/shard ID
• 16 bits: counter or RNG

Tradeoffs:

• Scope-limited uniqueness
• Tied to infrastructure layout
• Must be externally validated on sync

📡 Case Study 2: Telecom — Identity with Context

Telecom systems often need IDs that encapsulate network hierarchy, like:

• Region
• Equipment type
• Slot or rack

Example:

Benefits:

• Easier tracing across logs
• Inline diagnostics without lookup
• Real-world topology awareness

Used in:

• SIM/eSIM provisioning
• Mobile network ID flows
• Cell-to-cloud tracing

🌐 Case Study 3: IoT — Power & Bandwidth Limits

IoT devices often have:

• Very little RAM (e.g. 32KB)
• Limited flash storage
• Tight payload budgets (MQTT, CoAP, LoRa)

UUIDv4? Too big.

Solution:

Compressed binary identifiers, such as:

• 8-byte (64-bit) IDs with guaranteed uniqueness per manufacturer
• TLV (Type-Length-Value) formatted IDs to save bits
• Rolling counters + chip serial + device type

Example encoded format:

Tradeoffs:

• Shorter lifespan (e.g. wraparound)
• Requires strong manufacturer control
• Often tied to public key or secure enclave

🧠 When to Use Custom UUIDs

🔒 Security Considerations

Even domain-specific UUIDs must:

• Avoid predictability if exposed publicly
• Maintain entropy where needed
• Avoid leaking internal structure (unless intended)

Tip: use encryption or hashing if your UUID contains sensitive structure but must be exposed externally.

🧰 Implementation Tips

• Encode to Base58/Base64 if UUIDs will appear in URLs
• Benchmark performance of parsing, sorting, and hashing
• Use libraries like uuid, ulid, or ksuid as a base — then customize
• Store UUIDs in binary format where possible (16 bytes instead of 36-char string)

Final Thoughts

Standard UUIDs are brilliant. But when you’re working in extreme environments — or want identifiers that carry meaning, compress better, or generate faster — custom formats shine.

Understand your constraints. Then bend the standard thoughtfully.

🎮 🛰️ 🧠 Domain-specific UUIDs: engineered for your reality, not just RFC compliance.