Distributed Systems for Backend Engineers · Coordination
Unique IDs at Scale
UUIDv4, UUIDv7, ULID, Snowflake and database sequences.
Generating IDs without coordination: UUIDv4 (random; poor index locality), UUIDv7 (RFC 9562; time-ordered prefix + randomness — good B-tree locality, sortable), ULID (similar, Crockford base32), Snowflake (64-bit: timestamp + machine + sequence; compact, needs machine IDs), and database sequences (simple, central). Prefer UUIDv7 for most new systems; Snowflake when you need 64-bit integers.
ID schemes
| Criterion | UUIDv4 | UUIDv7 | Snowflake | DB sequence |
|---|---|---|---|---|
| Size | 128-bit | 128-bit | 64-bit | 64-bit |
| Time-ordered | No | Yes | Yes | Yes |
| Coordination | None | None | Machine IDs | Central DB |
| Index locality | Poor (random) | Good | Good | Best |
| Leaks info | No | Creation time | Time + machine | Volume (enumerable) |
import uuid
order_id = uuid.uuid7() # Python 3.14+: time-ordered RFC 9562 UUIDv7
# earlier versions: use a library such as uuid6/uuid-utils
-- PostgreSQL 18+: built-in uuidv7()
CREATE TABLE orders (id uuid PRIMARY KEY DEFAULT uuidv7(), created_at timestamptz DEFAULT now());
import { v7 as uuidv7 } from "uuid";
const orderId = uuidv7(); // sortable by creation time
Common pitfalls
- Random UUIDv4 primary keys on huge B-tree tables (write amplification).
- Exposing sequential IDs publicly (enumeration).
- Snowflake with duplicate machine IDs.
Key points
- UUIDv7 as a modern default
- Snowflake for 64-bit needs
- Don't expose enumerable IDs
Further reading: RFC 9562: UUIDs (including v7)
Practice questions
Why do UUIDv7 keys index better than UUIDv4?
Answer
Their time-ordered prefix makes new keys land near each other in B-trees, avoiding random page splits and improving cache locality.
What does a UUIDv7 reveal?
Answer
Its approximate creation timestamp, which may matter for privacy in some contexts.
Open in the app to mark lessons complete, take notes and track your progress.