Functional Requirements
What the system must do#
The Unique ID Generator is an internal service called by other backend systems whenever they need to assign a globally unique identifier — to a tweet, a message, an order, a user, anything.
There are four core requirements:
1. Generate globally unique IDs No two IDs should ever be the same, across any server, any region, at any point in time. This is the fundamental contract of the service.
2. IDs sortable by creation time Newer IDs should be greater than older IDs. This means you can sort a list of IDs and get chronological order for free — no need to store a separate created_at timestamp column just for ordering.
"Configurable sorting" is a trap
In an interview, if you say "sorting should be configurable," you've introduced scope creep. You're designing a specific system, not a generic framework. The real question is: what does the most common use case need? Systems like Twitter and Instagram need time-based ordering — that's the requirement. Lock it in.
3. IDs should be space-efficient IDs are stored everywhere — every table, every index, every foreign key reference. A bloated ID size compounds across billions of rows. The exact size is a design decision (covered in deep dives), but the requirement is that IDs should be as compact as possible without sacrificing uniqueness or ordering.
4. Machine-readable only This is an internal service. No human ever reads these IDs directly. They don't need to be memorable, pronounceable, or human-friendly — just something a database can store and a system can compare efficiently.