Chapter 21: Distributed ID Generation
In a distributed system, you can't use auto-increment IDs (multiple DBs would generate duplicates). You need globally unique IDs without coordination.
Options
| Method | Size | Sortable? | Pros | Cons |
|---|---|---|---|---|
| UUID v4 | 128 bit | No | No coordination needed | Large, random (bad for indexes) |
| Snowflake | 64 bit | Yes (time) | Compact, time-sorted, no coordination | Clock skew issues |
| ULID | 128 bit | Yes (time) | Lexicographically sortable, URL-safe | Larger than Snowflake |
| DB sequence | 64 bit | Yes | Simple | Single point of failure, not distributed |
Twitter Snowflake (64-bit)
┌─────────┬────────────────────────────┬──────────┬──────────────┐
│ 1 bit │ 41 bits │ 10 bits │ 12 bits │
│ (unused) │ timestamp (ms) │machine ID│ sequence │
└─────────┴────────────────────────────┴──────────┴──────────────┘
• Timestamp: milliseconds since epoch → sortable by time
• Machine ID: 1024 unique generators (no coordination between them)
• Sequence: 4096 IDs per millisecond per machine
• Total: ~4M IDs/sec per machine, globally unique, time-sorted
When to Use What
- UUID: simple, no infrastructure needed, acceptable for most cases
- Snowflake/ULID: need time-sorted IDs (feeds, events, logs)
- DB sequence: single database, simple app