How to Choose the Right Distributed ID Generator for Your System

System Requirements

Business systems typically need globally unique IDs that are either simply unique or also monotonically increasing. Uniqueness prevents primary‑key conflicts in sharded databases, while monotonicity improves write performance by enabling sequential inserts. Some use‑cases, such as distributed tracing, may not require monotonic IDs, but many database‑backed scenarios do. Additionally, predictable sequential IDs can leak business information, so security considerations may favor non‑sequential schemes.

Common ID Solutions

UUID

Snowflake‑like algorithms

Database auto‑increment primary keys

Redis atomic increment

UUID

UUID (Universally Unique Identifier) is provided by Java’s standard API. A standard UUID consists of 32 hexadecimal characters formatted as 8‑4‑4‑4‑12, totaling 36 characters (e.g., 630e4100-e29b-33d4-a635-246652140000). It requires no external dependencies and generates IDs quickly, but its long string wastes storage, is not auto‑incrementing (reducing insert performance), and carries no business meaning, making it suitable mainly for non‑database identifiers such as tracing request IDs.

Snowflake‑like Algorithm

The Snowflake algorithm, originally open‑sourced by Twitter, creates 64‑bit IDs divided into four parts:

1 bit: fixed 0 to indicate a positive integer.

41 bits: timestamp in milliseconds (supports ~69 years) – inherently monotonic.

10 bits: machine identifier (5‑bit datacenter ID + 5‑bit worker ID), supporting up to 1024 nodes.

12 bits: sequence number, allowing up to 4095 IDs per millisecond per node.

Advantages include business‑meaningful bits, monotonic IDs that boost database write performance, no third‑party dependencies, and protection against simple enumeration attacks because the increment step is not predictable. The main drawback is strong reliance on accurate system time; clock rollback can cause duplicate IDs, which can be mitigated by persisting the last timestamp locally.

Database Auto‑Increment Primary Key

Using a database’s auto‑increment column provides simple, low‑cost, monotonically increasing IDs. For low concurrency, a single instance can insert a row and return the generated key. However, this approach tightly couples ID generation to the database, creating a single point of failure and limiting scalability to the database’s write capacity. Scaling can be attempted by deploying multiple instances with stepped increments (e.g., three machines using steps of 3), but this introduces operational complexity and hampers horizontal scaling.

Redis Atomic Increment

Redis, as an in‑memory datastore, offers high‑performance atomic increments via the INCR command. The pattern mirrors database auto‑increment but stores the counter in memory, allowing higher throughput. Redis clusters and stepped increments can address scalability, yet the solution inherits the same drawbacks: dependence on Redis, operational overhead, and the need to handle persistence for durability.

Conclusion

When selecting an ID generation strategy, consider development cost, expected concurrency, performance, and operational overhead. UUID is easy but unsuitable for high‑performance database keys. Snowflake‑like algorithms provide short, monotonic, and secure IDs at the cost of implementation effort and time‑synchronization concerns. Database auto‑increment is simple but limited in scalability, while Redis atomic increment offers high concurrency at the expense of persistence management. For long‑term, high‑traffic systems, Snowflake‑like algorithms or a well‑engineered Redis solution are often the best choices.

References

Distributed System Global ID Generator Thoughts – Juejin

Leaf – Meituan Distributed ID Generation System

Six Ways to Implement a Global Unique ID Generator – CSDN Blog

Ensuring Global Uniqueness After Sharding – Technical Article