Distributed ID Generation Strategies: UUID, Auto‑Increment, Segment Mode, Redis, Snowflake, Baidu UidGenerator, Meituan Leaf, Didi TinyID

1. Why need distributed ID?

In monolithic systems, primary keys can be generated automatically, but after sharding databases in a distributed system the same auto‑increment strategy leads to duplicate IDs across tables, which does not meet business requirements.

2. Business requirements for distributed ID

Global uniqueness : IDs must be unique across the whole system.

Trend increasing : Ordered IDs improve write efficiency for MySQL InnoDB clustered indexes.

Monotonic increasing : Each new ID should be larger than the previous one, useful for versioning and sorting.

Security : IDs should not be strictly sequential to avoid easy scraping; irregular increments are preferred.

3. Distributed ID generation schemes

UUID

Database auto‑increment

Segment mode

Redis implementation

Snowflake algorithm

Baidu UidGenerator

Meituan Leaf

Didi TinyID

3.1 UUID

UUID (Universally Unique Identifier) is a 128‑bit value represented as 36 characters (8‑4‑4‑4‑12). Example: 863e254b-ae34-4371-87da-204b71d46a7b . The theoretical space is 2^128 ≈ 3.4×10^38.

Advantages

Very high performance; generated locally without network dependency.

Disadvantages

Large storage (16 bytes, 36‑character string).

Potential security issues if generated from MAC address.

Unordered nature can cause frequent data movement.

3.2 Database auto‑increment

MySQL auto‑increment can be used in a distributed environment by configuring auto_increment_increment and auto_increment_offset . For N machines, set step = N and assign different offsets, e.g., step = 2, Server 1 starts at 1 (1,3,5…) and Server 2 starts at 2 (2,4,6…).

Drawbacks: loss of monotonicity, high database load, and complex re‑configuration when scaling.

ID lacks strict monotonic increase.

Database pressure remains high.

3.3 Segment mode

The system obtains a range (e.g., [1,1000] ) from the database, loads the IDs into memory, and serves them locally. Table definition example:

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

Key fields:

biz_type : business category.

max_id : current maximum ID.

step : segment step size.

version : version for optimistic locking.

When IDs are exhausted, the service updates the max_id in the database:

update id_generator set max_id = #{max_id+step}, version = version + 1 where version = #{version} and biz_type = XXX

Pros: mature solution (e.g., Baidu UidGenerator, Meituan Leaf).

Cons: depends on the database.

3.4 Redis implementation

Redis provides atomic commands like INCR and INCRBY. Because Redis is single‑threaded, it guarantees uniqueness and ordering.

When request volume grows, a Redis cluster is required, which introduces similar segment/step configuration as traditional databases.

Pros : high performance, uniqueness, ordering.

Cons : introduces a Redis dependency.

3.5 Snowflake algorithm

Snowflake, open‑sourced by Twitter, generates 64‑bit IDs composed of:

1 bit sign (always 0).

41 bits timestamp (seconds since 2016‑05‑20, ~69 years).

10 bits machine ID (up to 1024 machines).

12 bits sequence per millisecond (up to 4096 IDs/ms).

Advantages : trend‑increasing IDs, no third‑party dependency, high efficiency, flexible bit allocation.

Disadvantages : relies on accurate system clocks; clock rollback can cause duplicate IDs or service downtime.

3.6 Baidu UidGenerator

Baidu's UidGenerator is a Java implementation based on Snowflake with improvements such as borrowing future timestamps and using a RingBuffer to cache IDs, achieving up to 600 k QPS per node.

UidGenerator works as a component, supports custom workerId bits and initialization strategies, suitable for Docker and instance restarts.

3.7 Meituan Leaf

Leaf offers two ID generation modes: segment (Leaf‑segment) and Snowflake (Leaf‑snowflake). The segment mode improves the classic segment approach by using a proxy server to batch‑fetch segments, reducing database load.

Table design:

+-------------+--------------+------+-----+-------------------+-----------------------------+
| Field       | Type         | Null | Key | Default           | Extra                       |
+-------------+--------------+------+-----+-------------------+-----------------------------+
| biz_tag     | varchar(128) | NO   | PRI |                   |                             |
| max_id      | bigint(20)   | NO   |     | 1                 |                             |
| step        | int(11)      | NO   |     | NULL              |                             |
| desc        | varchar(256) | YES |     | NULL              |                             |
| update_time | timestamp    | NO   |     | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
+-------------+--------------+------+-----+-------------------+-----------------------------+

Leaf‑snowflake keeps the same 1+41+10+12 bit layout as Snowflake but obtains worker IDs automatically via Zookeeper sequential nodes.

3.8 Didi TinyID

TinyID is a Java‑based distributed ID system built on the database segment algorithm, extending Leaf‑segment with multi‑database support and a client library.

Advantages: easy integration, mature solution.

Disadvantages: depends on database stability; requires master‑slave clustering for high availability.

TinyID wiki: https://github.com/didi/tinyid/wiki

Overall, each scheme balances trade‑offs among uniqueness, ordering, performance, scalability, and operational complexity, allowing architects to choose the most suitable solution for their specific business scenarios.