Distributed IDs

Business constraint

Many services need unique ids. Central autoincrement becomes a hotspot and a dependency.

Naive v0

UUID everywhere without thinking about index locality. Or one global sequence service.

Failure drill

Random UUIDs fragment B-Tree indexes. Global sequence caps write QPS and fails as a SPOF. Time-based ids leak timing or collide under clock rollback.

Evolution path

Iteration 1

Choose id scheme by primary access: time-ordered for range scans; random for unguessability; shard+seq for locality.

Iteration 2

Avoid hot partitions from time-only keys when writes spike on "now". Mix shard entropy.

Iteration 3

Document clock assumptions and collision probability.

Implementation cut

Treat id design as storage layout design. Load-test insert locality.

Numbers

Insert p99. Index fragmentation proxy. Collision rate (should be ~0).

Pattern tags

• shard-key-vs-time
• hot-key-tactics

Self-check

1. Why can UUIDv4 hurt indexes?
2. What fails in a global sequence?
3. How does shard+seq help?
4. What risk do time-based ids add?
5. How do you avoid hot time partitions?

Walkthrough

Recordings will appear here when published. Until then, work the failure drill and lab locally — pause after each iteration and write the metric that moved.