Design Distributed Unique ID Generator (Snowflake / UUIDv7)
High-performance distributed unique 64-bit ID generation architecture (Twitter Snowflake & UUIDv7) producing time-sortable, k-ordered, collision-free identifiers without cross-datacenter database locks.
1. System Requirements
- Generate globally unique 64-bit integer identifiers across hundreds of distributed microservices.
- Ensure generated IDs are roughly time-sortable (k-sortable) to maintain database B-Tree index clustering.
- Produce unique IDs locally with zero network coordination per ID generation request.
- Ultra-low latency: sub-millisecond generation (< 100 microseconds per ID).
- High availability (99.9999%): generator failures must never block upstream transaction pipelines.
- Resilient to NTP system clock drift and backwards clock synchronization adjustments.
2. Scale & Resource Estimates
Throughput: 100 Million IDs generated per second across 1,000 microservice nodes = 100,000 IDs/sec per instance.
Storage & RAM: 64-bit integer (8 bytes) footprint fits into standard CPU registers and relational BIGINT primary keys.
3. System API Endpoints
// Local Embedded In-Process SDK Call
const id = idGenerator.nextId();
// Returns: 1783709124982341632 (64-bit BIGINT)
// Optional HTTP Batch Generation Endpoint
GET /v1/ids/batch?count=100
Response:
{
"ids": [
"1783709124982341632",
"1783709124982341633",
"1783709124982341634"
]
}
4. Database Schema Design
64-Bit Bitwise Layout (Twitter Snowflake):
+--------------------------------------------------------------------------+
| 1 bit (Unused/Sign) | 41 bits (Timestamp ms) | 10 bits (Worker ID) | 12 bits (Sequence) |
+--------------------------------------------------------------------------+
- Bit 63: 0 (Fixed sign bit)
- Bits 22-62: Epoch milliseconds offset (41 bits = 2^41 ms ≈ 69.7 years lifespan)
- Bits 12-21: Machine / Datacenter Node ID (10 bits = 1024 unique instances)
- Bits 0-11: Sequence Counter (12 bits = 4096 unique IDs per millisecond per node)
Max Throughput: 1,024 nodes * 4,096 IDs/ms = 4,194,304,000 IDs per second.
5. Interactive High-Level Architecture
6. Scalability Deep Dive & Bottlenecks
Standard UUIDv4 (128-bit random) is an anti-pattern for database primary keys: random insertions cause severe B-Tree page splits and fragment disk caches, degrading insert throughput by 80%. Centralized auto-incrementing database counters create a single point of failure and bottleneck under high load. Snowflake solves this through structured bitwise arithmetic. The 41-bit timestamp component guarantees monotonic ordering for fast B-Tree appends; the 10-bit worker ID guarantees independence across servers; and the 12-bit sequence counter accommodates burst traffic.
7. Production Scaling Strategies
Clock Drift / Rollback Protection: If the local hardware clock jumps backward (e.g., NTP resynchronization), the generator detects `current_ms < last_ms`. If drift < 5ms, pause execution and spin-wait; if drift > 5ms, fail over to a backup worker ID lease or reject requests to prevent duplicate IDs.
Worker ID Coordination via Etcd: Machine IDs (0-1023) are dynamically leased from an Etcd/ZooKeeper cluster on pod startup with a 30-second TTL. Pods renew their lease via background heartbeats, enabling zero-touch auto-scaling in Kubernetes.
In-Process Embedding vs. Network RPC: Embed the ID generator as an in-process library (Go/Rust/Java/Node) rather than a remote microservice. This eliminates network round trips and socket allocation overhead entirely, achieving sub-microsecond generation.
UUIDv7 Alternative for Polyglot Stacks: For systems requiring 128-bit RFC standards, adopt UUIDv7 (48-bit Unix timestamp + 74-bit random/sequence), which maintains B-Tree locality while avoiding centralized machine ID coordination.
High-Frequency Sequence Overflow: If a single node generates more than 4,096 IDs within a single millisecond, the sequence counter overflows (bits rollover). The generator spin-waits until the next millisecond tick before resuming generation.
Database Index Performance Boost: Because IDs are time-ordered, new database writes always append to the rightmost leaf node of the B+ Tree. This keeps active leaf pages resident in the buffer pool, maximizing cache hits.
8. Runnable Production Starter Code
Scaffold