Generating Unique IDs
Practice this topic in a realistic system design interview
Every entity in a system needs an identifier: a user, an order, a message, a shortened URL. On a single database, an auto-incrementing column handles this well. The database owns one counter and hands out the next value on each insert.
The problem appears with multiple independent writers. If each writer keeps its own local counter and the ID space is not partitioned, two writers can produce the same value. The IDs are no longer unique.
At interview scale, ID generation is about more than uniqueness. You also need to think about ordering, length, predictability, database index locality, clock behavior, and operational failure modes.
A good interview answer compares the trade-offs instead of naming one universal best ID scheme.
Interview Answer Shape
In an interview, choose the ID scheme from requirements:
- Clarify uniqueness scope, generation rate, ID length, sortability, and whether IDs are public.
- Start with auto-increment when there is one primary writer and predictable public IDs are acceptable.
- Use UUID v4, UUID v7, or ULID when decentralized generation matters more than compact 64-bit IDs.
- Use Snowflake-style IDs when you need compact, time-sortable IDs and can safely assign machine IDs.
- Mention operational safeguards: unique constraints, collision handling for random or truncated IDs, node ID assignment, and clock-backward behavior.