Eight Distributed ID Generation Strategies: Pros, Cons, and Implementation Guide

In recent technical interviews, distributed systems topics such as distributed transactions, locks, scheduling, storage, and especially distributed ID generation are frequently asked. When data volume grows and sharding is applied, a globally unique identifier is needed for records across multiple databases and tables, which is precisely what distributed IDs provide.

1. UUID

UUID (Universally Unique Identifier) consists of 32 hexadecimal characters plus four hyphens (36 characters total) and offers an extremely low collision probability. The most common version is UUID‑v4, generated randomly. In Java it can be created with a single line of code:

import java.util.UUID;
public class Test {
    public static void main(String[] args) {
        System.out.println("Generated UUID: " + UUID.randomUUID());
    }
}

Advantages: Simple implementation, no external dependencies, high generation performance.

Disadvantages: Non‑sequential, large storage (32 characters even without hyphens), poor readability.

2. Database Auto‑Increment ID

Use a central database table with an auto‑increment primary key to generate IDs. Example SQL:

REPLACE INTO id_table (stub) VALUES ('a');
SELECT LAST_INSERT_ID();

Advantages: Monotonically increasing, good readability.

Disadvantages: Requires a database round‑trip for each ID, adds latency, increases system complexity, and puts load on the central DB.

3. Redis INCR Command

Redis can generate sequential IDs using the INCR command. Example:

127.0.0.1:6379> set distributed_id 1   // initialize
OK
127.0.0.1:6379> incr distributed_id   // increment and return
(integer) 2

Advantages: Monotonic, high generation performance, easy readability.

Disadvantages: Requires an additional Redis instance, introduces a longer call chain, and recovery after Redis failure can be slow.

4. Snowflake Algorithm

Twitter’s Snowflake generates 64‑bit IDs composed of four parts: 1 sign bit (always 0), 41 bits for a millisecond‑precision timestamp (supporting ~69 years), 10 bits for a machine identifier (up to 1024 nodes), and 12 bits for a per‑millisecond sequence (up to 4096 IDs per node per ms).

Advantages: Simple implementation, monotonic, low error rate, high performance.

Disadvantages: Relies on synchronized clocks; clock rollback can cause duplicate IDs, and IDs are not human‑readable.

5. Database Segment

Improves the basic auto‑increment approach by allocating a batch (segment) of IDs from the central DB and caching them locally. When a segment is exhausted, a new batch is fetched. Table schema example:

CREATE TABLE id_generator (
  id int NOT NULL,
  max_id bigint NOT NULL COMMENT 'current max id',
  step int NOT NULL COMMENT 'segment length',
  biz_type int NOT NULL COMMENT 'business type',
  version int NOT NULL COMMENT 'optimistic lock version',
  PRIMARY KEY (id)
);

Advantages: Monotonic, high generation performance, reduced DB pressure, good readability.

Disadvantages: Higher development cost and added service layer increase failure points.

6. Meituan Leaf

Leaf implements both segment and Snowflake modes. The Leaf‑snowflake variant follows the same 1+41+10+12 bit layout but runs as an independent service and uses Zookeeper to mitigate clock‑rollback issues.

Advantages: Monotonic, solves clock‑rollback duplication, high performance.

Disadvantages: Requires third‑party open‑source software, introduces a dedicated ID service and Zookeeper, and IDs are not easily readable.

7. Didi Tinyid

Tinyid builds on the segment model, supporting multi‑master databases and offering pre‑loading of ID segments. When the used portion of a segment reaches a threshold (default 20%), the next segment is loaded asynchronously.

Advantages: Monotonic, high performance, low DB pressure, good readability.

Disadvantages: Requires additional ID service and central DB, increasing system complexity.

8. Baidu UidGenerator

UidGenerator is a Java component based on Snowflake, allowing custom worker‑ID bits and initialization strategies. It uses a future‑time trick and a RingBuffer to achieve up to 6 million QPS on a single machine.

Bit layout:

1 sign bit (positive).

28 bits for timestamp (seconds since 2016‑05‑20, ~8.7 years).

22 bits for machine ID (≈4.2 million nodes).

13 bits for per‑second sequence (up to 8192 IDs per second).

Advantages: Monotonic, local generation, extremely high performance.

Disadvantages: Third‑party library learning curve, clock‑rollback risk, limited readability.

Conclusion

Among the eight schemes, Snowflake and database segment are the most widely adopted. However, the best choice depends on the specific characteristics and requirements of your system.