Distributed writers still need unique identities#
A single database sequence is wonderfully simple. When many regions or shards must generate IDs independently, the design must trade central coordination against size, ordering, index locality, clock behavior, and collision risk.
| Strategy | Strength | Trade-off |
|---|---|---|
| Database sequence | Simple, ordered, constraint-backed | Central dependency or allocation coordination |
| UUID-style | Decentralized, huge space | Larger keys; ordering/locality depends on version and representation |
| Random short ID | Compact public identifier | Collision probability, retry/check strategy |
| Snowflake-style | Distributed and roughly time ordered | Clock, node identity, per-tick sequence capacity |
Snowflake-style IDs combine locally available fields#
┌──────────── timestamp ────────────┬── node ──┬─ sequence ─┐
│ rough time ordering │ writer │ same-tick │
└──────────────────────────────────┴───────────┴────────────┘The node field prevents writers from sharing the same sequence space; the sequence handles multiple IDs in one time bucket. Plan for clock rollback, duplicate node IDs, and sequence exhaustion. Exposed structure can leak approximate time or traffic information.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- RFC 9562: Universally Unique IDentifiersIETF / RFC Editor