Choosing the right ID strategy
UUID v4 is a safe default for many distributed systems where centralized counters are hard to coordinate.
Human-readable IDs can help UX, but machine IDs should prioritize uniqueness and stability.
- Use UUID for distributed write paths.
- Use slugs for user-facing URLs, not internal identity.
- Avoid reusing IDs across environments.
Operational pitfalls
ID bugs often appear as merge conflicts, accidental overwrites, or difficult audit trails.
Treat IDs as immutable references once persisted.
- Do not regenerate IDs for existing rows.
- Store IDs as canonical lowercase where possible.
- Validate incoming IDs at API boundaries.
Testing and fixtures
In tests, random IDs improve realism but can make snapshots noisy.
Use controlled fixture IDs where deterministic output matters.
- Use stable IDs in golden tests.
- Use generated UUIDs for load and collision checks.
- Document ID format requirements in API specs.
FAQ
Can UUID collisions happen?
In theory yes, but with UUID v4 and strong randomness they are extremely unlikely in practical application scales.
Should IDs include business meaning?
Usually no. Embedding semantics in IDs can create coupling and migration pain.
Can I expose internal IDs publicly?
You can, but review privacy and enumeration risks first. Public IDs should be stable and non-sensitive.