Common UUID Use Cases — When and Where to Actually Use Them

UUIDs solve a specific problem: generating an identifier that is unique without coordination. That uniqueness guarantee is valuable in some places and overkill in others. Here are the use cases where UUIDs genuinely earn their 16 bytes — and the patterns engineers reach for them.

1. Database Primary Keys (Distributed Systems)

The classic use case. When a record can be created on any node — multiple servers, mobile clients writing offline, microservices owning their own databases — auto-incrementing integers cause collisions during reconciliation. UUIDs let any node mint a key that will never collide with another node's.

The catch: random v4 UUIDs scatter inserts across a B-tree index, hurting write performance. For database primary keys, prefer UUID v7 (time-ordered) or ULID. Both keep the cross-node uniqueness while sorting chronologically — so inserts cluster at the end of the index, just like auto-increment.

2. User-Uploaded File Names

Never trust a filename a user uploads. Replace it with a UUID:

// Bad:  /uploads/${originalFilename}
// Good: /uploads/${uuid}.${extension}

UUID filenames prevent path traversal (no ../../etc/passwd), eliminate collisions when two users upload resume.pdf, and make the URL unguessable so a user can't enumerate other users' files.

3. API Keys, Session Tokens, Reset Codes

A v4 UUID has 122 bits of cryptographic randomness — more than enough entropy for a session token or password reset link. Convenient, fast to generate, and uses a well-tested random source.

Caveat: UUIDs are not the most compact format. If token length matters (e.g., URL query strings), Base64-encoded random bytes are shorter. And for long-lived secrets like API keys, rotate them regularly — entropy alone doesn't replace good key management.

4. Idempotency Keys

Critical for payments, order placement, and any non-idempotent operation that might be retried. The client generates a UUID and sends it with the request. The server stores the UUID with the result; if the same UUID arrives again, it returns the cached result instead of charging the card a second time.

Stripe, AWS, and most payment APIs use this pattern. UUID v4 is ideal here — randomness is the whole point, since predictable keys could let one client overwrite another's operation.

5. Request Correlation / Trace IDs

In a microservice architecture, one user request triggers calls across many services. A correlation ID — generated at the entry point and propagated through every downstream call — lets you stitch logs back together. UUIDs work, though distributed tracing standards (W3C Trace Context, OpenTelemetry) often use shorter formats optimized for the use case.

6. Event IDs in Event-Sourced Systems

Every event in an event log needs a unique ID for deduplication, ordering, and replay. UUID v7 is increasingly the default choice: events sort by ID alone (no separate timestamp index needed), and there's no coordination required between event producers.

7. Cache Keys for Versioned Resources

When a resource changes, you can change its cache key by associating each version with a UUID. CDN caches, browser caches, and asset pipelines often use UUID-named files (app.a3f2c891.js) so updates invalidate cleanly without cache-purge complexity.

Where UUIDs Are Overkill

• Single-node systems with simple data. A blog with one database and no integrations doesn't need UUIDs. Auto-increment is simpler, faster, smaller.
• User-facing identifiers. Order numbers, ticket IDs, and reference codes that humans read should be short and memorable. ORD-2026-04812 beats 550e8400-e29b-41d4-a716-446655440000 every time.
• Anything where storage is the bottleneck. 16 bytes per row, multiplied across every index and foreign key, adds up. At billion-row scale, UUID overhead becomes measurable.

Quick Reference: Which Version When?

• UUID v4 (random) — tokens, file names, idempotency keys, anything where unpredictability matters and sort order doesn't.
• UUID v7 (time-ordered) — database primary keys, event IDs, anything that goes in a B-tree index or needs to sort chronologically.
• UUID v1 — historical. Avoid: it leaks the generating machine's MAC address and creation time.
• UUID v3 / v5 — namespace UUIDs (deterministic from a name + namespace). Useful for content-addressed identifiers but rarely the right tool.

The right UUID for the right job is usually the difference between "works fine" and "why is our database index 60% wasted space." Pick deliberately.