Designing a Distributed ID Generation Service

In a microservices world, primary keys must be unique across all shards and databases. Relying on an auto-incrementing database column is not an option as it creates a central point of failure.

1. Requirements

• Unique: No two requests ever get the same ID.
• Time-Sorted (k-sorted): IDs should generally increase over time to optimize database B-Tree index insertions.
• 64-bit Size: Must fit within a standard database integer field.
• Availability: Service must never go down.

2. The Snowflake Architecture

Twitter's Snowflake algorithm is the industry standard for this task. It generates a 64-bit ID:

• 1-bit: Unused (sign bit).
• 41-bits: Timestamp (ms).
• 10-bits: Machine/Worker ID.
• 12-bits: Sequence number (resets every millisecond).

3. Scaling and Autonomy

• Worker ID Assignment: Use a configuration service like Zookeeper or Etcd to assign unique IDs to each worker node dynamically when they start up.
• Clock Drift: If a server's time goes backward (due to NTP sync), the generator must detect it and wait to prevent duplicate IDs.

4. Why 64-bits matters

By keeping IDs to 64 bits, we avoid the overhead of storing 128-bit UUIDs, resulting in smaller indexes and faster queries in relational databases like PostgreSQL and MySQL.

5. Throughput limits and sequence overflow

In Snowflake-style systems, per-node throughput per millisecond is bounded by sequence bits.

With 12 sequence bits:

• max 4096 IDs per millisecond per worker
• if exhausted, generator must wait for next millisecond tick

This behavior should be measured under peak bursts so latency side effects are understood.

6. Clock rollback handling strategies

Clock rollback is the hardest production issue for time-based IDs.

Options:

• block generation until clock catches up
• switch to "logical offset" mode temporarily
• fail-fast and remove unhealthy node from service

Blindly continuing after rollback can create duplicate IDs across workers.

7. Worker ID lifecycle management

Worker identity must be unique across active nodes and restarts.

Best practices:

• lease-based worker ID assignment via etcd/Zookeeper
• startup fencing to prevent old and new processes sharing same worker ID
• explicit recycle delay before reusing released IDs

ID correctness depends as much on control plane as generation algorithm.

8. Multi-region design concerns

Global deployments can partition worker ID spaces by region:

• reserve high bits for region/datacenter
• keep worker uniqueness only within region slice
• use region-aware decoding for debugging and routing

This reduces cross-region coordination while preserving uniqueness.

9. Operational observability

Track:

• IDs generated per worker per second
• sequence overflow frequency
• clock drift/rollback incidents
• worker ID assignment conflicts

These metrics reveal saturation and correctness risk before incidents hit application data.

10. Snowflake vs UUID vs database sequence

• Snowflake: compact, sortable, distributed
• UUIDv4: globally unique, not naturally sortable, larger indexes
• DB sequence: simple and strict ordering, poor horizontal scaling

Choose based on sharding needs, storage efficiency, and ordering requirements.

11. Migration and interoperability tips

When migrating from old IDs:

• support dual ID fields during transition
• maintain mapping table for legacy references
• avoid changing public API contracts abruptly

Distributed ID adoption is easiest when treated as incremental infrastructure migration.

Summary

The distributed ID service is one of the most elegant pieces of distributed infrastructure. By using bit-wise packing and decentralized worker IDs, you eliminate the need for global coordination, allowing your system to scale horizontally forever.